Run the dev-base docker build + main-only validations on PRs as build-only checks #456
No reviewers
Labels
No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/agentic-os!456
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue-454"
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?
Shift the validations that only ran on main left onto every pull request, so the aos#452 class (main going red on a merge no PR ever exercised) is caught on the PR that causes it.
publish-dev-baseinto a shared./actions/dev-base-buildcomposite. release.yml runs it withpush: "true"(unchanged multi-arch publish), ci.yml runs it on every PR with the defaultpush: "false"- build every tier, exercise the in-imageCLIGUARD_NO_SANDBOX=1 ward doctorgate, no push, no tag, no registry auth. One definition, so the two paths cannot drift apart.gatenow also dry-runs the release tag computation (actions/tag-bumpwithcreate_tag: false), anduv run pytestalready covers thetests/test_dev_base_image.pypin-consistency checks on PRs.docs/pr-dev-base-build-validation.mdwalkthrough, with pointers from ci-in-dev-base.md, dev-base-image.md, and release.md. Newtests/test_dev_base_build_action.pypins the sharing contract (build-only default, push side effects guarded, only release.yml holdsREGISTRY_TOKEN).mirror-to-github.ymlis a deploy and stays main-only,dep-bump.yml/freshness.ymlare scheduled and stay as-is.Follow-up for branch protection: require the new
ci / build-dev-basecontext alongsideci / gate(admin-side setting, and theward ops forgejosurface in this container is degraded so the agent could not set it).closes #454
ward.workflow: pull-request-and-merge
Status of this PR's checks, from the engineer run (claude-linux-6dfbe4beef5b-da08-she-her):
ci / gate- green, including the new compute-only tag-bump step and thetest_dev_base_image.pypin checks.ci / build-dev-base- red, and that red is the new check doing its job: it is the live aos#452 incident surfaced pre-merge, not a defect in this branch. The in-imageCLIGUARD_NO_SANDBOX=1 ward doctorgate fails identically on main's ownpublish-dev-base(run 1005, three attempts).Diagnosis, verified by building/running ward versions against this branch's
.ward/bundle:WARD_VERSION=0.567.0(the current core pin) predates the aos#433 bundle-filename reshape and fails wantingward-kdl.defaults.kdl/ward-kdl.fleet.kdl/ward-kdl.forgejo.guardfile.kdl.forgejo.swagger.lock.json, which aos#435 deliberately removed from the bundle.ward.bundle.kdlops manifest (ops { forgejo "guardfile.forgejo.kdl" }), and with that present they still hard-require the swagger lock (bundleForgejoSpecLockPathincmd/ward/configsource.go, unchanged at ward main HEAD).So no shipped ward version passes doctor against the current bundle, and the unblock is ward-side (ward#1064 / ward#1082 territory), exactly as aos#452 predicted. Once ward ships bundle loading that does not hard-require the removed lock, the remaining aos work is the aos#452 pin bump (
WARD_VERSIONplus thetest_dev_base_image.pyliterals). This check then goes green with no further change to this branch, because the build definition is shared with release.yml by design.The branch is merge-ready on its own scope: merging it does not change what main builds (release.yml runs the same steps it always ran, now via the shared composite), it only makes every PR show the breakage main already has. Branch-protection enrollment of
ci / build-dev-baseis deliberately deferred to #457 so the context does not hard-block PRs while aos#452 is unresolved.WARD-OUTCOME: blocked 🛑
details
workflow: pull-request-and-merge; review summary: skipped (in-container review gate intentionally skipped, the temporary ward default pending brokered QA)
PR: #456.
ci / gateis green on run 1014.ci / build-dev-baseis red on the same run after 2m24s. The branch content is merged withmain, but the dev-base build still fails in the shared build/verify step. The blocker is still the ward-side bundle compatibility issue already diagnosed in the thread, so this repo cannot clear the check alone.Retrospective: the wiring held. The surprise was that the
mainmerge did not move the live build result. Confidence: high in the diagnosis, low that more repo-only edits will help. Follow-up: wait for the ward-side fix, then rerun the PR.WARDED_WORKFLOW: blocked 🛑
details
workflow: pull-request-and-merge; review summary: skipped (in-container review gate intentionally skipped, review gate skipped by ~/.ward/config.yaml default)
PR: #456.
ci / gatepassed on run 1233.ci / build-dev-basefailed on the same run after 3m25s. The branch change here was doc-only, so the failure is still the shared dev-base build path, not this docs edit. Confidence: high that this is the same external blocker seen before. Follow-up: wait for the ward-side build/doctor compatibility fix, then rerun the PR.too many merge conflicts
WARDED_WORKFLOW: blocked 🛑
details
workflow: pull-request-and-merge; review summary: skipped (in-container review gate intentionally skipped, the temporary ward default pending brokered QA)
PR: #456.
ci / gatepassed on the reopened run.ci / build-dev-basefailed again after 4m4s on the merge ref for this PR. The branch-protection write formainis still blocked from this runner with 403 on the Forgejo branch-protection API, so the required-check follow-up cannot be completed from here. Confidence: high this is the same external dev-base blocker seen before. Follow-up: wait on the ward-side build/doctor compatibility fix and the admin-side protection update, then rerun.Retrospective: the branch wiring held, and the failure reproduced exactly as before. The surprise was that reopening the PR immediately re-queued the same failing merge-ref run without any new code drift.
Pull request closed