fix(ci): rebuild the image when a build input outside docker/ changes #1094

Closed

coilyco-ops wants to merge 1 commit from aos/claude/wt57-image-inputs-filter into main

coilyco-ops commented

2026-08-16 06:14:33 +00:00

Owner

The verb you just merged in #1093 cannot reach a runner. Found while checking
what happens after the merge.

What is wrong

The dev-base path filters watch only docker/**, but docker-bake.hcl pulls
three build contexts from elsewhere in the repo:

aosguard-spec   = ".specgen"
aosguard-python = "agentic_os"
repo-lists      = "aos-cli/repositories"

promote.yml is unfiltered, so a change to any of them reaches the release
branch and looks landed. dev-base-publish then matches none of its watched
paths and never fires, so :release keeps the older binary.

The failure is silent in both directions. No job fails, and the change appears
released. #1093 is on main and on release right now, and aosguard ops telegram alert exists in neither the published image nor any runner.

This is not specific to #1093. It covers every past guardfile edit and every
change to the embedded Python package.

dev-base-pr.yml carried the identical filter, so PR-time image validation
skipped these inputs too. #1093 was never image-validated before merge either.

The fix

Both filters now watch every build context. The test derives the expected paths
from docker-bake.hcl's own contexts blocks rather than restating them, so a
new context outside docker/ fails the check until its path is watched.

Verified by mutation: dropping .specgen/** from the filter fails the test with
build contexts absent from the path filter: ['dev-base-publish.yml: .specgen'].
Full file passes 12/12.

Still needed after this merges

This repairs the trigger going forward. #1093 already landed under the old
filter, so it needs one dev-base-publish dispatch to reach the registry.
Say the word and I will fire it, or you can, since it republishes the image
every CI job in the fleet pulls.

The verb you just merged in #1093 cannot reach a runner. Found while checking what happens after the merge. ## What is wrong The dev-base path filters watch only `docker/**`, but `docker-bake.hcl` pulls three build contexts from elsewhere in the repo: ``` aosguard-spec = ".specgen" aosguard-python = "agentic_os" repo-lists = "aos-cli/repositories" ``` `promote.yml` is unfiltered, so a change to any of them reaches the `release` branch and looks landed. `dev-base-publish` then matches none of its watched paths and never fires, so `:release` keeps the older binary. The failure is silent in both directions. No job fails, and the change appears released. #1093 is on main and on release right now, and `aosguard ops telegram alert` exists in neither the published image nor any runner. This is not specific to #1093. It covers every past guardfile edit and every change to the embedded Python package. `dev-base-pr.yml` carried the identical filter, so PR-time image validation skipped these inputs too. #1093 was never image-validated before merge either. ## The fix Both filters now watch every build context. The test derives the expected paths from `docker-bake.hcl`'s own `contexts` blocks rather than restating them, so a new context outside `docker/` fails the check until its path is watched. Verified by mutation: dropping `.specgen/**` from the filter fails the test with `build contexts absent from the path filter: ['dev-base-publish.yml: .specgen']`. Full file passes 12/12. ## Still needed after this merges This repairs the trigger going forward. #1093 already landed under the old filter, so it needs one `dev-base-publish` dispatch to reach the registry. Say the word and I will fire it, or you can, since it republishes the image every CI job in the fleet pulls.

coilyco-ops added 1 commit

2026-08-16 06:14:34 +00:00

fix(ci): rebuild the image when a build input outside docker/ changes

ci / ward-doctor (pull_request) Successful in 13s

Details

ci / aos-cli-tests (pull_request) Successful in 18s

Details

ci / gate (pull_request) Successful in 51s

Details

adadf6d45a

The dev-base path filters watched only `docker/**`, but docker-bake.hcl pulls
three build contexts from elsewhere in the repo:

    aosguard-spec   = ".specgen"
    aosguard-python = "agentic_os"
    repo-lists      = "aos-cli/repositories"

So a change to any of them promoted from main to release and never rebuilt the
image that ships it. `promote.yml` is unfiltered, so the commit reaches
`release` and looks landed, while `dev-base-publish` skips it and `:release`
keeps the older binary. The failure is silent in both directions: no job fails,
and the change appears released.

Found immediately after #1093 landed `aosguard ops telegram alert`. That verb is
on main and in the release branch right now, and no runner can call it, because
a guardfile-only change matches none of the watched paths. The same hole covers
every past guardfile edit and every change to the embedded Python package.

`dev-base-pr.yml` carried the identical filter, so PR-time image validation
skipped these inputs too. A guardfile change was never image-validated before
merge either.

The test derives the expected paths from docker-bake.hcl's own `contexts`
blocks rather than restating them, so a new context outside docker/ fails the
check until its path is watched. Verified by mutation: dropping `.specgen/**`
from the filter fails the test.

This fixes the trigger going forward. The already-merged #1093 still needs one
`dev-base-publish` dispatch to reach the registry.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-16 06:14:34 +00:00