Repository navigation
Add the reusable workflow an automatic deploy rule pins - #8
Draft
nick-potts wants to merge 2 commits into
Draft
nick-potts wants to merge 2 commits into
nick-potts wants to merge 2 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the
|
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.
Why
Ployz 0.4 lets a Server build a push under an automatic deploy rule without trusting Ployz Cloud. The rule pins a builder by commit. GitHub writes the builder's file and commit into the run's OIDC token (
job_workflow_ref,job_workflow_sha), so the Server can check that this builder ran and that the caller added no steps to its job. The composite action atgetployz/build@v1can't be pinned that way, so this adds a reusable workflow next to it.What it does
.github/workflows/build.ymlis aworkflow_callwith two inputs.cloudis the Ployz Cloud origin.commitis optional and defaults to the commit GitHub ran.inputs.commit || github.shawithpersist-credentials: false. It never checks out a commit Cloud names.ployzCLI fromPLOYZ_URLand checks it againstPLOYZ_SHA256.crazy-max/ghaction-github-runtime, pinned by commit).ployzpasses it to Buildx only when the rule's policy turns the cache on, and scopes it by the policy's digest.ployz build --cloud --commit --source --events.ployzmakes the build's own holder and recipient keys and requests a token for each audience. It opens the build secrets only when the Cluster's attest key sealed them. Buildx gets a fresh environment, soACTIONS_ID_TOKEN_REQUEST_TOKENnever reaches BuildKit, andACTIONS_RUNTIME_TOKENreaches it only when the cache is on.Every action is pinned by commit.
Before merge
PLOYZ_URLandPLOYZ_SHA256point at a lab build ofployzfrom the Ployz PR that addsployz build --cloud. Before merge, they move to the first Ployz release that carries it.BUILDER_SHA). A merge commit or a rebase keeps that commit reachable. A squash merge makes a new one, and Ployz's pin moves to it.Proof
Live lanes ran against a Ployz Cluster with Device enforcement on, from a lab fork of this branch:
ref;job_workflow_sha;