Skip to content

Use matching prebuilt images for package builds and publishing - #552

Merged
ryanrhughes merged 1 commit into
ci/daily-builder-imagesfrom
ci/use-daily-builder-images
Sep 20, 2026
Merged

ryanrhughes merged 1 commit into
ci/daily-builder-imagesfrom
ci/use-daily-builder-images

Conversation

@ryanrhughes

@ryanrhughes ryanrhughes commented Sep 20, 2026 •

Copy link
Copy Markdown
Collaborator

Fresh DO package jobs currently rebuild the Arch environment even when a tested image exists. Enable matching prebuilt images for PR package builds, missing-artifact builds during publishing, and the publishing tools themselves.

Depends on #551; this PR is based on its branch so the integration can be reviewed separately. Merge the producer first, complete its initial public GHCR publication, then retarget this PR to master and merge.

Image selection uses this checkout's build context, architecture, and mirror. Verify the image's compatibility label and platform, then use its immutable registry digest for every container in that build invocation. Missing, private, unavailable, or mismatched images fall back to the existing local build and pin that image's ID. A failed fallback remains a job failure.

The workflow/script checkout behavior is unchanged. Local builds remain opt-in; explicit prepared-image mode retains precedence. Each package still gets a fresh container and a full Arch update before dependency installation. Publishing prepares its image before the step receives signing credentials.

Validation: 46 local regression tests pass, including matching images, incompatible metadata, registry failures, failed fallback builds, immutable references in actual bin/build invocations, and the publishing preparation step. Shell syntax checks and actionlint pass. A real local-registry integration check pulled the matching production builder by digest and compiled and packaged a C program through bin/build. All PR checks pass, including full candidate image builds and isolation tests on native x86_64 and ARM runners.

No control-box update is needed. Reverting this integration restores local image construction while leaving the daily producer available.

@ryanrhughes
ryanrhughes merged commit 2f69c67 into ci/daily-builder-images Sep 20, 2026
9 checks passed
APS6 pushed a commit to APS6/omarchy-pkgs that referenced this pull request Sep 26, 2026
Moves the pin from f7ea7ecc to the head of quattro-upstream, which adds
omacom#552's reset-prepare, reset-verify, reset-commit and reset-rollback
entrypoints, omacom#553's luks-slots entrypoint and recovery key handling,
omacom#556's encrypt unit output to kmsg at notice, and omacom#560's snapshot restore
check with its limine-snapper-sync pre and post hooks. The pin's UTC date is
still 20260925, so pkgrel goes to 4. omacom#544 is not in it, so the Plymouth
fragment still ships and no HOOKS baseline dependency applies.
APS6 pushed a commit to APS6/omarchy-pkgs that referenced this pull request Sep 26, 2026
…ntrypoints need

omarchy-lifecycle-dispatch requires reset-* (omacom#552) and luks-slots (omacom#553) on
Apple Silicon, so a runtime carrying them before this package blocks factory
reset, owner setup and omarchy-drive-password on Macs.
@maralcbr

maralcbr commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator

Hi Ryan, I think this PR never made it into master.

It was based on #551's branch, ci/daily-builder-images. #551 merged into master at 20:49 UTC on 2026-09-20, and this one merged six minutes later, still targeting ci/daily-builder-images. It was never retargeted, and the repo doesn't auto-delete head branches, so GitHub didn't retarget it either. c433bb5c ("Reuse matching daily builder images in package jobs") only exists on the two ci/* branches, and master has no OMARCHY_PREBUILT_IMAGES.

So the daily images are built and published but never used: every package build still builds its own image from build/Dockerfile. That bit us yesterday. keys.openpgp.org was down for about 10 hours, and the pacman-key --recv-keys step at build/Dockerfile:116 failed every aarch64 build, including #803, until it came back.

c433bb5c still cherry-picks onto master with a single conflict, in .github/workflows/build-pr.yml. Happy to put up a draft PR with the conflict resolved and you as author, if that helps, or leave it with you. Might also be worth turning on "Automatically delete head branches" so stacked PRs get retargeted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants