The handbook names the appliance check build-and-boot and describes its old behaviour #9

New issue

Open

opened 2026-09-28 01:10:41 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-28 01:10:41 -03:00

(Migrated from github.com)

Keel-Linux/.github#12 renames the reusable appliance job build-and-boot to
boot-published-layer, so the check is appliance / boot-published-layer, and
makes a layer that has never been published fail the job instead of passing it.
The ten caller repositories are updated with it. The handbook still carries the
old name and, in two places, the old behaviour:

docs/ci-cd.md, section on check names: "test-appliance.yml (job id
build-and-boot), so its check is exactly: appliance / build-and-boot".
docs/ci-cd.md, the new-repository procedure: "its check is
appliance / build-and-boot and it is required only once it has passed
once, because it depends on a layer being published". The reason is now
different: it fails while the layer is unpublished, rather than passing
vacuously.
docs/ci-cd.md, the keel-nodebb note and the keel-core row of the table.
docs/releases-host.md, "Publishing a layer": "appliance / build-and-boot
skips with a notice and passes. Publishing a layer is therefore what turns
that check from a skip into a real run." It now fails rather than skipping.

Worth adding at the same time, because it is the substance of that pull
request and not only a rename: the check boots the layer the mirror publishes,
so on a pull request that changes a recipe it is evidence about code that is
already merged. The procedure in docs/ci-cd.md that tells a maintainer to
require it should say so, and should say which way renaming a required check
fails. GitHub fails closed: a required context that is never reported leaves
the pull request blocked, waiting for a status that will never arrive, so a
rule left on the old name locks the repository rather than quietly ceasing to
apply. Measured on keel-mariadb on 2026-09-28: pull request 16, reporting
appliance / build-and-boot, clean; pull request 17, reporting
appliance / boot-published-layer and identical otherwise, blocked. Rename
the rule in the same change.

unit-mariadb, unit-postgresql and unit-redis each mention
build-and-boot once in a header comment as well; those are prose, not gates.

Keel-Linux/.github#12 renames the reusable appliance job `build-and-boot` to `boot-published-layer`, so the check is `appliance / boot-published-layer`, and makes a layer that has never been published fail the job instead of passing it. The ten caller repositories are updated with it. The handbook still carries the old name and, in two places, the old behaviour: - `docs/ci-cd.md`, section on check names: "`test-appliance.yml` (job id `build-and-boot`), so its check is exactly: `appliance / build-and-boot`". - `docs/ci-cd.md`, the new-repository procedure: "its check is `appliance / build-and-boot` and it is required only once it has passed once, because it depends on a layer being published". The reason is now different: it fails while the layer is unpublished, rather than passing vacuously. - `docs/ci-cd.md`, the keel-nodebb note and the keel-core row of the table. - `docs/releases-host.md`, "Publishing a layer": "`appliance / build-and-boot` skips with a notice and passes. Publishing a layer is therefore what turns that check from a skip into a real run." It now fails rather than skipping. Worth adding at the same time, because it is the substance of that pull request and not only a rename: the check boots the layer the mirror publishes, so on a pull request that changes a recipe it is evidence about code that is already merged. The procedure in `docs/ci-cd.md` that tells a maintainer to require it should say so, and should say which way renaming a required check fails. GitHub fails closed: a required context that is never reported leaves the pull request blocked, waiting for a status that will never arrive, so a rule left on the old name locks the repository rather than quietly ceasing to apply. Measured on keel-mariadb on 2026-09-28: pull request 16, reporting `appliance / build-and-boot`, `clean`; pull request 17, reporting `appliance / boot-published-layer` and identical otherwise, `blocked`. Rename the rule in the same change. `unit-mariadb`, `unit-postgresql` and `unit-redis` each mention `build-and-boot` once in a header comment as well; those are prose, not gates.