ci: deploy/Dockerfile auf pull requests bauen - #30
Merged
Conversation
deploy/Dockerfile wurde bislang ausschliesslich im Release-Workflow und im manuellen publish-image-Workflow gebaut. test.yml deckte nur Go ab. Eine Regression im Dockerfile fiel damit erst im naechtlichen release.yml auf, also nach dem Merge. Genau dieser Fall war #24: der Renovate-Custom-Manager hob INFISICAL_CLI_VERSION an, ohne INFISICAL_CLI_SHA256 mitzuziehen, und matchManagers ["dockerfile"] steht auf automerge. Der PR waere ungeprueft gemerged worden und haette den Release-Build zerrissen. Neuer Job docker-build baut dasselbe Dockerfile mit push: false. GHA-Cache haelt die Laufzeit nach dem ersten Lauf klein. Damit Renovates platformAutomerge tatsaechlich darauf wartet, muss "docker-build" noch in den Required Status Checks der Branch-Protection von main eingetragen werden - sonst mergt GitHubs Auto-Merge am Job vorbei.
There was a problem hiding this comment.
Pull request overview
This PR closes a CI gap by ensuring deploy/Dockerfile is built on pull requests (and main pushes) as part of the existing test workflow, so Dockerfile regressions are detected before merge rather than only during release/publish workflows.
Changes:
- Add a new
docker-buildjob to.github/workflows/test.yml. - Build
deploy/Dockerfilewithdocker/build-push-actionusingpush: falseand GHA cache (type=gha).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+80
to
+83
| # deploy/Dockerfile wurde bis dahin nur im Release gebaut — eine Regression darin fiel erst | ||
| # im naechtlichen release.yml auf, nach dem Merge (siehe #24). Dieser Job baut dasselbe | ||
| # Dockerfile ohne Push, damit sie vor dem Merge auffaellt. Damit Renovates automerge darauf | ||
| # wartet, muss "docker-build" in den Required Status Checks der main-Branch-Protection stehen. |
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
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.
Struktureller Nachzug zu #24. Behebt kein offenes Issue, sondern die Lücke, durch die #24 überhaupt bis in einen Release hätte durchrutschen können.
Problem
deploy/Dockerfilewurde bislang ausschließlich inrelease.yml(nächtlicher Cron) undpublish-image.yml(manuell) gebaut.test.ymldeckt nur Go ab —go build,go vet,go test -race, Coverage-Gate, Doc-Coverage. Eine Regression im Dockerfile fiel damit erst nach dem Merge auf.Genau dieser Fall war #24: Der Renovate-Custom-Manager hebt
INFISICAL_CLI_VERSIONan, ohneINFISICAL_CLI_SHA256mitzuziehen, undmatchManagers: ["dockerfile"]steht aufautomerge: true. Der PR wäre ungeprüft gemerged worden und hätte den nächsten Release-Build zerrissen. Die Ursache ist mit #28 weg — die Lücke, die das unbemerkt ließ, bleibt ohne diesen PR bestehen.Änderung
Ein Job
docker-buildintest.yml, der dasselbe Dockerfile mitpush: falsebaut. GHA-Cache (type=gha) hält die Laufzeit nach dem ersten Lauf klein. Keine Registry-Logins, keine Secrets — der Job braucht nichts davon, weil nichts gepusht wird.Der Job muss in die Required Status Checks der Branch-Protection von
maineingetragen werden. Ohne das wartet GitHubs Auto-Merge — und damit RenovatesplatformAutomerge— nicht auf ihn, und der Job liefe zwar, könnte einen kaputten PR aber nicht aufhalten. Der Schutz wäre dann kosmetisch.Das ist eine Repo-Einstellung und lässt sich nicht im Code mitliefern. Ich habe sie bewusst nicht selbst gesetzt.
Verifikation
test.ymlparst als YAML, Jobs sindlint,test,docker-buildrelease.yml(docker/setup-buildx-action@v4,docker/build-push-action@v7,file: deploy/Dockerfile), damit PR-Build und Release-Build nicht auseinanderlaufendocker-buildmuss in seinen eigenen Checks grün auftauchen🤖 Generated with Claude Code