Pass --build to every docker compose run in AGENTS.md

[ThisIsMissEm]

Context & Requests for Reviewers

Whilst working on #1193, I encountered an issue with claude running the test suite, unbeknownst to me, it was actually reusing the existing container from a previous run, this meant that when I thought I'd run all the tests following changes, I'd actually run the previous containers code & tests, not the latest changes.

docker compose run only builds when no image exists yet, so the documented commands reuse a stale image and report on code that isn't in the container. That falsifies the CI section's claim that each command's exit code matches the corresponding CI step's.

Tests

n/a, changes agents.md

(Optional) Rollout Plan

n/a

Checklist

Only check items that apply to this PR; leave the rest unchecked.

• If you changed anything user-facing (i.e. user interface or APIs):
  Did you update related docs?

• If the change is notable (refer to Keep a Changelog conventions):
  Did you update CHANGELOG.md?

• If you changed server/models/**/{ContentTypeModel,ActionModel,RuleModel,PolicyModel}.ts:
  Did you update the corresponding history tables and their triggers?

• If you changed db/src/scripts/** and used CREATE TABLE, ADD COLUMN, or ALTER COLUMN:
  Are as many columns marked NOT NULL as possible? If some columns can sometimes be null depending on other columns, are there CHECK constraints capturing those relationships, and are these also reflected using unions in the associated Kysely types?

• If you added a new signal in server/services/signalsService/signals/**:
  Did you classify every error case as a permanent error (SignalPermanentError, no retry) or a normal error (retryable)? Any case where the signal can't determine a score should be a SignalPermanentError.

Summary by CodeRabbit

• Documentation
  • Updated Docker Compose command examples to include the --build flag.
  • Clarified that Compose may otherwise run tests against a stale image.
  • Updated testing, CI, and individual-check guidance to consistently rebuild images before execution.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 6cd0e4f1-aebd-48ea-bf29-497ed47b3b72

📥 Commits

Reviewing files that changed from the base of the PR and between 033e6b0 and cc922a1.

📒 Files selected for processing (1)

• AGENTS.md

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.

---

📝 Walkthrough

Walkthrough

AGENTS.md now adds --build to Docker Compose test, CI, table, and example commands. It also explains that Compose can otherwise run a stale image.

Changes

Compose build guidance

Layer / File(s)	Summary
Update Compose command guidance AGENTS.md	Testing, CI, individual-check, and ROOST example commands now pass --build. The Testing section explains the stale-image behavior.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~5 minutes

Change: Other

Suggested reviewers: juanmrad

Merge Risk: ⚪ Minimal · up to cc922

This documentation-only update reduces stale-image test results without introducing an actionable merge risk.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: adding --build to every documented docker compose run command in AGENTS.md.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch emelia/agents-docker-compose-build

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ThisIsMissEm]

Arguably this should be kept the same, though it is weird to build development tools into a baked docker image..

[juanmrad]

I was thinking about this as I was looking at the pr. And the --build is only needed because the compose services use COPY instead of volume mounts.

For local dev, mounting the source directories would keep the container in sync without rebuilding. That avoids the --build tax entirely and makes the feedback loop faster. I think we can update docker-compose.yaml to mount ./server and ./client into the respective services instead?

[ThisIsMissEm]

I'm not sure if that'd actually help here, due to how volume mounts end up working with the node_modules directories and with .dockerignore — really I don't think we should be running lint, build, or test within the container typically in developer workflows: we already have those tools all existing locally via npm install — with a volume mount we'd end up with macos deps running inside a linux container which would obviously break.

The chances of drift here between the CI and local copy is next to none, bar maybe platform specific issues, since the only additional software in the container is dumb-init. Platform specific issues would be things we'd need to get fixed anyway in order to make the project contributor friendly.

[juanmrad]

I think I understand the concern now. Mounting ./server over /app would overlay the image’s existing /app, including its Linux-installed node_modules. We could preserve those with a separate /app/node_modules volume or narrower source mounts, but that requires additional Compose design.

I don’t think .dockerignore affects runtime bind mounts. It only controls the Docker build context. Either way, with the current setup the source is baked into the images, so adding --build makes sense.