CI: boot-published-layer blocks the very fix the published layer needs #53

Closed
opened 2026-10-03 02:00:32 -03:00 by marcos-mendez · 1 comment
marcos-mendez commented 2026-10-03 02:00:32 -03:00 (Migrated from github.com)

The required check appliance / boot-published-layer boots the layer currently published on the mirror. When that layer carries a bug that stops the first boot (2026-10-03: inithooks keel18 died on logger without journald and blocked on an unread tty1), every PR in every appliance repo fails the check, including the changelog bump that the next layer needs (keel-core#24 needed an admin bypass with the check removed; keel-core#25 is stuck the same way), and the only way out is to publish a new layer first.

Options: (a) the job upgrades the rootfs from trixie-testing (chroot apt-get full-upgrade) before booting, so it tests the published layer plus current packages, which is also what an operator running apt upgrade gets; (b) the check stays required but a repo's own package PRs run a lighter job (build + install in a chroot) and only layer-affecting changes run the boot; (c) keep it, and accept a manual bypass each time a published layer is broken. I recommend (a). Found while running release step 4 on 2026-10-03.

The required check `appliance / boot-published-layer` boots the layer currently published on the mirror. When that layer carries a bug that stops the first boot (2026-10-03: inithooks keel18 died on `logger` without journald and blocked on an unread tty1), every PR in every appliance repo fails the check, including the changelog bump that the next layer needs (keel-core#24 needed an admin bypass with the check removed; keel-core#25 is stuck the same way), and the only way out is to publish a new layer first. Options: (a) the job upgrades the rootfs from trixie-testing (chroot apt-get full-upgrade) before booting, so it tests the published layer plus current packages, which is also what an operator running apt upgrade gets; (b) the check stays required but a repo's own package PRs run a lighter job (build + install in a chroot) and only layer-affecting changes run the boot; (c) keep it, and accept a manual bypass each time a published layer is broken. I recommend (a). Found while running release step 4 on 2026-10-03.
marcos-mendez commented 2026-10-03 11:26:30 -03:00 (Migrated from github.com)

Fixed by Keel-Linux/.github#20: the boot gate now upgrades the published layer from trixie-testing (and installs the PR's .deb when given) inside the container before the first-boot test. Follow-up: keel-core and keel-web must pass their built .deb to the appliance job.

Fixed by Keel-Linux/.github#20: the boot gate now upgrades the published layer from trixie-testing (and installs the PR's .deb when given) inside the container before the first-boot test. Follow-up: keel-core and keel-web must pass their built .deb to the appliance job.
Sign in to join this conversation.
No description provided.