Repository navigation
Reusable publish-fragment workflow, and the render diff on the app PR #135
Description
Activity
- added
on Oct 1, 2026 The dispatch App exists (JorisJonkers-dev/estate#1):
- App:
estate-dispatch, id5165539. Permissions:actions: write,contents: read,statuses: write,metadata: read. Installed on all repositories in the org. - Org variable
ESTATE_DISPATCH_APP_IDand org secretESTATE_DISPATCH_APP_PRIVATE_KEY, both with visibilityall. A caller's reusable workflow reads them asvars.ESTATE_DISPATCH_APP_IDandsecrets.ESTATE_DISPATCH_APP_PRIVATE_KEY(passsecrets: inherit, or the secret by name). - Composition is dispatched with a token minted for
JorisJonkers-dev/estate, e.g.actions/create-github-app-tokenwithowner: JorisJonkers-devandrepositories: estate.compose.ymlon estate is still the canary stage,workflow_dispatchonly. JorisJonkers-dev/estate#2 defines the real trigger and its inputs. - The signer the artifacts must verify against is
https://github.com/JorisJonkers-dev/estate/.github/workflows/compose.yml@refs/heads/main. Fragments are signed by the publishing repository's own identity, not this one.
- App:
Two things this ticket was waiting on have landed:
- The CLI: feat: compose the estate, and the deploy-kit command that validates, publishes and composes deploy-kit#228 merged, so
deploy-kit validate,publishandcomposeare onmain. Ship the deploy-kit command in the published package deploy-kit#229 (shipping the command in the published package) is still in triage, so a workflow cannotnpxit from a release yet. - The Migration Proof: feat: the runner image, its up and down commands, and the Migration Proof action liquibase-runner#3 added a composite action,
JorisJonkers-dev/liquibase-runner/actions/migration-proof. It runs the three migration-safety obligations against a throwaway Postgres and writesmigration-proof.ymlbeside the project file.publish-fragmentshould run after it, because the fragment's digest covers the proof. Its inputs are in that repository's README.
- The CLI: feat: compose the estate, and the deploy-kit command that validates, publishes and composes deploy-kit#228 merged, so
#136 merged the two pieces this ticket asks for: the reusable
publish-fragment.ymlworkflow and theactions/render-diffstep. The ticket stays open for its acceptance line, home-portal publishing through it on a tag. What that still needs:- A deploy-kit release that ships the command. feat: ship the deploy-kit command in the published package, built when it is packed deploy-kit#237 adds the
deploy-kitbin to the package; it reaches callers with the next release (chore(main): release 0.3.0 deploy-kit#75). A caller pinning an earlier release fails the workflow's install step, by design, with a message saying so. - A release of this repository. The workflow checks this repository out at the release tag release-please writes into it, so a caller pins the release that first contains
actions/publish-fragment, notmain. - The images-lock share (Pack each project fragment's share of the images lock, and union the shares in composition deploy-kit#230). The toolkit cannot pack it yet, so the workflow does not write one.
- The real composition workflow (JorisJonkers-dev/estate#2). The dispatch starts
compose.yml, which is still the canary. That ticket also builds the step that pulls the estate's inputs, andactions/render-diffreads the directory it leaves:platform/,fragments/<project>/,cluster-state.yml, and optionallyheld/,pins.jsonandprevious/. - The caller (Move home-portal onto the estate path, the first Project home-portal#70): a
package.jsonand lockfile pinning@jorisjonkers-dev/deploy-kit, a tag-triggered job that calls the workflow after its images are built, andsecrets: inheritor the dispatch App's key by name.
For JorisJonkers-dev/estate#2: fragments are signed by
https://github.com/JorisJonkers-dev/github-workflows/.github/workflows/publish-fragment.yml@<ref>, and the publishing repository is in the certificate (--certificate-github-workflow-repository).latestonghcr.io/jorisjonkers-dev/intent-<project>only moves forward, and every release also has its own version tag.- A deploy-kit release that ships the command. feat: ship the deploy-kit command in the published package, built when it is packed deploy-kit#237 adds the
#138 added the images-lock share:
publish-fragment.ymltakes animages-lock-artifactinput and hands the lock todeploy-kit publish --images-lock, which packs only the aliases the project file names. That closes the "images-lock share" item in the list above on this side; the option itself lands in deploy-kit with JorisJonkers-dev/deploy-kit#238.For the caller (JorisJonkers-dev/home-portal#70): the build job writes
images.lock.yml(anImagesLockdocument: each image the release pushed, by digest, with the numeric uid and gid it runs as), uploads it as an artifact, and passes the artifact's name. deploy-kit's workedproject-publish-fragment.ymlshows one way to write it. Composition resolves a Project only from its own share and the Platform document's lock, so every alias the project file names has to be in one of the two.
Parent
JorisJonkers-dev/deploy-kit#195
What to build
publish-fragmentworkflow application repositories call on a release tag. It validates the project file with the pinned deploy-kit, resolves every image (and the migration image) to a digest, writes the images-lock share and the migration proof, pushes the keyless-signed OCI Intent Fragment carrying the release version, and dispatches composition inJorisJonkers-dev/estatewith a GitHub App token.Acceptance criteria
Blocked by