ci: switch image publishing to docker/github-builder#2008
ci: switch image publishing to docker/github-builder#2008PromoFaux merged 1 commit intopi-hole:developmentfrom
Conversation
crazy-max
force-pushed
the
github-builder
branch
from
5409d07 to
f6d10dd
Compare
Signed-off-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>
crazy-max
force-pushed
the
github-builder
branch
from
f6d10dd to
e974aea
Compare
| - development | ||
| release: | ||
| types: [published] | ||
| pull_request: |
There was a problem hiding this comment.
Added pull_request event so workflow can be tested to avoid regressions. We could probably merge build-and-publish.yml with this one as follow-up.
There was a problem hiding this comment.
I'll follow this up - I don't recall exactly why I split publish/test out to two distinct workflows, but I think it was just to keep things nice and readable. Less of an issue now...
|
Thanks! |
We can pre-check the development workflow on the https://github.com/pi-hole/docker-pi-hole/actions/runs/23194244321 |
PromoFaux
left a comment
PromoFaux
left a comment
There was a problem hiding this comment.
Checked on experimental branch - looks good to me
|
Thanks @crazy-max - I go on holiday for one week and come back to a vastly simplified* build yaml... I should go on holiday more often! 😅 * Though I understand the actual process in the background is just as, if not more, complex than what this replaces. I like that it effectively offloads the actual build implementation logic to a Docker-maintained workflow |
3 participants
follow-up docker/buildx#3708 (comment)
Description
This PR switches the image build and publish workflow to the Docker GitHub Builder reusable workflow. This keeps the multi-platform image publishing flow while reducing repository-specific GitHub Actions logic.
More info: https://docs.docker.com/build/ci/github-actions/github-builder/
Motivation and Context
This change simplifies the CI pipeline compared to Docker's distributed multi-runner workflow. It removes the need for custom per-platform orchestration, digest artifact handoff, and a separate manifest merge step. It also gives us a more consistent Docker-maintained build path with better provenance and lower maintenance overhead.
How Has This Been Tested?
The workflow configuration was reviewed to confirm that the build arguments, tag strategy, publishing targets, and push behavior remain aligned with the current process. No application runtime code paths were changed in this PR. End-to-end validation will occur in the next
developmentworkflow run and the next release publication.Types of changes
Checklist:
cc @yubiuser