admin/orchestrator
1
0
Fork 0
Code Issues Pull Requests 3 Actions 1 Packages Projects Releases Wiki Activity

fix(docker): drop COPY of gitignored data/ so staging builds from a worktree (ORCH-061) #64

Closed
admin wants to merge 1 commits from feature/ORCH-061-bug-deploy-staging-development into main
pull from: feature/ORCH-061-bug-deploy-staging-development
merge into: admin:main
Conversation 1 Commits 1 Files Changed 5 +110 -1
admin commented 2026-06-07 16:39:30 +03:00
Owner
Copy Link

Summary

Fixes the second cause of the deploy-staging -> development loop (ORCH-061).

After the C9a/C9b infra-FAIL waiver (PR #62) let the pipeline progress, it reached the staging-image rebuild (check_staging_image_fresh, ORCH-058) and failed there: the Dockerfile had COPY data/ ./data/, but data/ is gitignored (runtime SQLite DB + backups) and therefore absent in every git worktree. The staging rebuild uses the task worktree as the docker build context -> docker build failed (rc=1) -> rollback to development.

  • Replace COPY data/ ./data/ with RUN mkdir -p /app/data. The DB always arrives via the compose bind mount (./data:/app/data), so baking it in was pointless (and leaked a stale host DB into the image).
  • Add static regression guard tests/test_dockerfile_worktree_buildable.py: the Dockerfile must never COPY a gitignored path (would re-break worktree builds).
  • Docs: CHANGELOG, architecture README (build-context invariant), 10-tech-risks (R-9 realized).

No contract changes: STAGE_TRANSITIONS, QG_CHECKS, hook exit-codes, OCI revision label, DB schema, compose volumes all unchanged.

Test plan

  • pytest tests/ — 673 passed
  • new guard test passes (3 cases)
  • CI green on branch
  • staging rebuild (--build-staging) now succeeds from the worktree context
## Summary Fixes the second cause of the `deploy-staging -> development` loop (ORCH-061). After the C9a/C9b infra-FAIL waiver (PR #62) let the pipeline progress, it reached the staging-image rebuild (`check_staging_image_fresh`, ORCH-058) and failed there: the `Dockerfile` had `COPY data/ ./data/`, but `data/` is **gitignored** (runtime SQLite DB + backups) and therefore absent in every git worktree. The staging rebuild uses the task **worktree** as the docker build context -> `docker build` failed (rc=1) -> rollback to development. - Replace `COPY data/ ./data/` with `RUN mkdir -p /app/data`. The DB always arrives via the compose bind mount (`./data:/app/data`), so baking it in was pointless (and leaked a stale host DB into the image). - Add static regression guard `tests/test_dockerfile_worktree_buildable.py`: the Dockerfile must never `COPY` a gitignored path (would re-break worktree builds). - Docs: CHANGELOG, architecture README (build-context invariant), 10-tech-risks (R-9 realized). No contract changes: `STAGE_TRANSITIONS`, `QG_CHECKS`, hook exit-codes, OCI revision label, DB schema, compose volumes all unchanged. ## Test plan - [x] `pytest tests/` — 673 passed - [x] new guard test passes (3 cases) - [ ] CI green on branch - [ ] staging rebuild (`--build-staging`) now succeeds from the worktree context
admin added 1 commit 2026-06-07 16:39:30 +03:00
fix(docker): drop COPY of gitignored data/ so staging image builds from a worktree
All checks were successful
CI / test (push) Successful in 17s
Details
CI / test (pull_request) Successful in 16s
Details
01684a89df 
The staging-image rebuild (check_staging_image_fresh, ORCH-058) uses the task
git worktree as the docker build context. `data/` is gitignored (runtime SQLite
DB + backups) so it is absent in every worktree -> `COPY data/ ./data/` failed
the build (rc=1) -> deploy-staging rolled back to development (the loop ORCH-061
targets, surfaced one step later once the C9a/C9b waiver let the pipeline reach
the rebuild). The DB always arrives via the compose bind mount, so baking it in
was pointless (and leaked a stale host DB into the image).

Replace `COPY data/ ./data/` with `RUN mkdir -p /app/data` and add a static
regression guard asserting the Dockerfile never COPYs a gitignored path.

Refs: ORCH-061

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
admin commented 2026-06-08 10:55:32 +03:00
Author
Owner
Copy Link

Superseded: ORCH-061 already merged via PR#62/#63. Duplicate branch, closing without merge.

Superseded: ORCH-061 already merged via PR#62/#63. Duplicate branch, closing without merge.
admin closed this pull request 2026-06-08 10:55:32 +03:00
All checks were successful
CI / test (push) Successful in 17s
Details
CI / test (pull_request) Successful in 16s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/orchestrator#64
Delete Branch "feature/ORCH-061-bug-deploy-staging-development"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?