Run the dev-base docker build + main-only validations on PRs as build-only checks #456

Closed
coilyco-ops wants to merge 2 commits from issue-454 into main
Member

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.

  • Factor the build/verify half of publish-dev-base into a shared ./actions/dev-base-build composite. release.yml runs it with push: "true" (unchanged multi-arch publish), ci.yml runs it on every PR with the default push: "false" - build every tier, exercise the in-image CLIGUARD_NO_SANDBOX=1 ward doctor gate, no push, no tag, no registry auth. One definition, so the two paths cannot drift apart.
  • gate now also dry-runs the release tag computation (actions/tag-bump with create_tag: false), and uv run pytest already covers the tests/test_dev_base_image.py pin-consistency checks on PRs.
  • The publish manifest-verify loop derives its tier refs from the build plan instead of a hand-maintained suffix list.
  • New docs/pr-dev-base-build-validation.md walkthrough, with pointers from ci-in-dev-base.md, dev-base-image.md, and release.md. New tests/test_dev_base_build_action.py pins the sharing contract (build-only default, push side effects guarded, only release.yml holds REGISTRY_TOKEN).
  • Audited the other main-only workflows: mirror-to-github.yml is a deploy and stays main-only, dep-bump.yml / freshness.yml are scheduled and stay as-is.

Follow-up for branch protection: require the new ci / build-dev-base context alongside ci / gate (admin-side setting, and the ward ops forgejo surface in this container is degraded so the agent could not set it).

closes #454

ward.workflow: pull-request-and-merge

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. - Factor the build/verify half of `publish-dev-base` into a shared `./actions/dev-base-build` composite. release.yml runs it with `push: "true"` (unchanged multi-arch publish), ci.yml runs it on every PR with the default `push: "false"` - build every tier, exercise the in-image `CLIGUARD_NO_SANDBOX=1 ward doctor` gate, no push, no tag, no registry auth. One definition, so the two paths cannot drift apart. - `gate` now also dry-runs the release tag computation (`actions/tag-bump` with `create_tag: false`), and `uv run pytest` already covers the `tests/test_dev_base_image.py` pin-consistency checks on PRs. - The publish manifest-verify loop derives its tier refs from the build plan instead of a hand-maintained suffix list. - New `docs/pr-dev-base-build-validation.md` walkthrough, with pointers from ci-in-dev-base.md, dev-base-image.md, and release.md. New `tests/test_dev_base_build_action.py` pins the sharing contract (build-only default, push side effects guarded, only release.yml holds `REGISTRY_TOKEN`). - Audited the other main-only workflows: `mirror-to-github.yml` is a deploy and stays main-only, `dep-bump.yml` / `freshness.yml` are scheduled and stay as-is. Follow-up for branch protection: require the new `ci / build-dev-base` context alongside `ci / gate` (admin-side setting, and the `ward ops forgejo` surface in this container is degraded so the agent could not set it). closes #454 ward.workflow: pull-request-and-merge
ci: run the dev-base build + main-only validations on PRs as build-only checks
Some checks failed
ci / gate (pull_request) Successful in 11s
ci / build-dev-base (pull_request) Failing after 2m20s
7c51971514
Factor the build/verify half of release.yml's publish-dev-base into the
shared ./actions/dev-base-build composite so PR validation and the main
publish run one definition and cannot drift apart. ci.yml gains a
pull_request-only build-dev-base job that builds every tier (exercising
the in-image CLIGUARD_NO_SANDBOX=1 ward doctor gate) with no push, no
tag, and no registry auth, plus a compute-only tag-bump step in gate so
release planning is validated pre-merge. Publish, tag, and the GitHub
mirror stay main-only. The manifest verify loop now derives its tier
refs from the build plan instead of a hand-maintained suffix list.

This is the prevention for the aos#452 class: main going red on a merge
because PRs never exercised what main does.

closes #454
Author
Member

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 the test_dev_base_image.py pin 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-image CLIGUARD_NO_SANDBOX=1 ward doctor gate fails identically on main's own publish-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 wanting ward-kdl.defaults.kdl / ward-kdl.fleet.kdl / ward-kdl.forgejo.guardfile.kdl.
  • v0.582.0 through v0.604.0 read the new names but hard-require forgejo.swagger.lock.json, which aos#435 deliberately removed from the bundle.
  • v0.605.0+ additionally want a ward.bundle.kdl ops manifest (ops { forgejo "guardfile.forgejo.kdl" }), and with that present they still hard-require the swagger lock (bundleForgejoSpecLockPath in cmd/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_VERSION plus the test_dev_base_image.py literals). 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-base is deliberately deferred to #457 so the context does not hard-block PRs while aos#452 is unresolved.

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 the `test_dev_base_image.py` pin 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-image `CLIGUARD_NO_SANDBOX=1 ward doctor` gate fails identically on main's own `publish-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 wanting `ward-kdl.defaults.kdl` / `ward-kdl.fleet.kdl` / `ward-kdl.forgejo.guardfile.kdl`. * v0.582.0 through v0.604.0 read the new names but hard-require `forgejo.swagger.lock.json`, which aos#435 deliberately removed from the bundle. * v0.605.0+ additionally want a `ward.bundle.kdl` ops manifest (`ops { forgejo "guardfile.forgejo.kdl" }`), and with that present they still hard-require the swagger lock (`bundleForgejoSpecLockPath` in `cmd/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_VERSION` plus the `test_dev_base_image.py` literals). 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-base` is deliberately deferred to #457 so the context does not hard-block PRs while aos#452 is unresolved.
Merge remote-tracking branch 'origin/main' into issue-454
Some checks failed
ci / gate (pull_request) Successful in 11s
ci / build-dev-base (pull_request) Failing after 2m24s
bb4d2ede0a
Author
Member

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 / gate is green on run 1014. ci / build-dev-base is red on the same run after 2m24s. The branch content is merged with main, 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 main merge 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.

WARD-OUTCOME: blocked 🛑 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (in-container review gate intentionally skipped, the temporary ward default pending brokered QA) PR: #456. `ci / gate` is green on run 1014. `ci / build-dev-base` is red on the same run after 2m24s. The branch content is merged with `main`, 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 `main` merge 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. </details> <!-- ward-agent-signature -->
coilysiren closed this pull request 2026-07-13 02:57:41 +00:00
coilyco-ops reopened this pull request 2026-07-14 09:05:35 +00:00
Author
Member

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 / gate passed on run 1233. ci / build-dev-base failed 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.

WARDED_WORKFLOW: blocked 🛑 <details><summary>details</summary> 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 / gate` passed on run 1233. `ci / build-dev-base` failed 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. </details>
Owner

too many merge conflicts

too many merge conflicts
coilysiren closed this pull request 2026-07-14 11:13:28 +00:00
coilyco-ops reopened this pull request 2026-07-14 15:27:31 +00:00
Author
Member

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 / gate passed on the reopened run. ci / build-dev-base failed again after 4m4s on the merge ref for this PR. The branch-protection write for main is 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.

WARDED_WORKFLOW: blocked 🛑 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (in-container review gate intentionally skipped, the temporary ward default pending brokered QA) PR: #456. `ci / gate` passed on the reopened run. `ci / build-dev-base` failed again after 4m4s on the merge ref for this PR. The branch-protection write for `main` is 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. </details>
coilysiren closed this pull request 2026-07-15 00:55:47 +00:00
Some checks failed
ci / gate (pull_request) Successful in 11s
ci / build-dev-base (pull_request) Failing after 2m24s

Pull request closed

Sign in to join this conversation.
No description provided.