ci: publish test/docker/* images to the GitHub Container Registry - #445
Merged
Merged
Conversation
Every test/docker/*/Dockerfile FROMs a ghcr.io/proot-me/proot:<tag>
image, but nothing in this repo builds or pushes them. They only
existed if someone built and pushed manually.
Three jobs, one per distro, run in parallel; each builds its own
base -> x86_64 -> {gcc,clang} chain sequentially so every FROM
resolves against the image built earlier in the same job, no pull or
substitution needed. Triggers on push to master when test/docker/**
or the tag-parsing script changes, plus workflow_dispatch for a
manual rebuild.
Tags come from util/parse-docker-tag.awk, the same script
test/test-docker.sh already uses for local builds, rather than
reimplementing that logic in YAML. Verified its output directly
against every Dockerfile path this workflow builds, and verified the
build chain itself: built debian and debian-x86_64 locally with the
real ghcr.io/proot-me/proot:* tag strings (not substituted local
ones) and confirmed the x86_64 layer's FROM resolved against the
locally-built base with no pull needed, exactly like this workflow's
sequential steps will. All three full distro chains were already
verified end-to-end for #444.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
SonarCloud (S8233): least-privilege hardening for GitHub Actions. Every job here happens to need packages: write, but declaring it at the workflow level applies it to any job added later too, whether or not that job actually needs it.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every `test/docker/*/Dockerfile` FROMs a `ghcr.io/proot-me/proot:` image, but nothing in this repo actually builds or pushes them, confirmed by grepping the whole `.github/workflows/` tree for `ghcr.io`/`docker/login-action`/`docker/build-push-action` before writing this. They only ever existed if someone built and pushed them manually.
Three jobs, one per distro (alpine, centos, debian), run in parallel. Each builds its own `base -> x86_64 -> {gcc,clang}` chain sequentially within the job, so every `FROM` resolves against the image built earlier in the same job's Docker daemon, no pull or tag substitution needed. Triggers on push to `master` when `test/docker/**` or the tag-parsing script changes, plus `workflow_dispatch` for a manual rebuild.
Tags come from `util/parse-docker-tag.awk`, the same script `test/test-docker.sh` already uses for local builds, rather than reimplementing that logic in YAML: one source of truth for the naming scheme. Verified its output directly against every Dockerfile path this workflow actually builds (not just the docstring's example).
Verified the build chain mechanism too, not just the YAML: built `debian` and `debian-x86_64` locally with the real `ghcr.io/proot-me/proot:*` tag strings (not substituted local ones like #444 used) and confirmed the `x86_64` layer's `FROM` resolved against the locally-built base with no pull needed, exactly like this workflow's sequential steps will. All three full distro chains (base through both compiler variants) were already verified end-to-end while working on #444.
No third-party GitHub Actions added; uses plain `docker login`/`build`/`push` CLI commands, matching this repo's existing preference for minimal external action dependencies (only `actions/checkout` is used anywhere else in this repo's workflows).