sha is the full 40-char SHA in build-bundle.yml's output and
build-docker.yml's new checkout-pinning input, matching git and
GitHub's own convention. short_sha stays internal to each workflow
for the S3 keys and image tags that already used it — build-bundle.yml
no longer exposes it externally since nothing outside consumed it.
No S3 key, image tag, or marker value changes anywhere.
Signed-off-by: David Barragán Merino <david.barragan@kaleidos.net>
_DEVELOP and _STAGING chain build-bundle.yml -> build-docker.yml,
both invoked with gh_ref as a branch name. Each reusable workflow
re-resolves that branch with its own checkout, at its own time.
build-docker's checkout happens minutes after build-bundle's, after
new commits can have landed on the branch, so it can compute a
different sha than the one build-bundle actually bundled and
uploaded to S3.
The Prepare job then requests a key that was never uploaded:
fatal error: An error occurred (404) when calling the HeadObject
operation: Key "penpot-sha-<newer-sha>.zip" does not exist
Expose build-bundle.yml's resolved sha as a workflow_call output and
thread it through _DEVELOP, _STAGING and _ADHOC as build-docker.yml's
new optional sha input, which pins its checkout instead of
re-resolving gh_ref. gh_ref keeps naming the branch tag to move.
_TAG is unaffected: it builds from a pushed git tag, which cannot
move the way a branch can, so build-bundle and build-docker already
agree on one commit there.
Signed-off-by: David Barragán Merino <david.barragan@kaleidos.net>
The bundle and docker-image build/dedup checks used different cache
keys: the bundle was cached by ref name (`penpot-<gh_ref>.zip`) while
the docker image marker was cached by commit sha
(`markers/images-sha-<sha>`). A tag built from a commit already
promoted under another ref (e.g. `develop`) would rebuild the bundle
unnecessarily, while `build-docker`'s `promote` job silently inherited
the skip from `build` and never created that ref's branch tags
(`backend:<gh_ref>`, `frontend:<gh_ref>`, ...), even though the
underlying sha-tagged images already existed.
- Key the bundle S3 object by commit sha (`penpot-sha-<sha>.zip`)
instead of by ref name, matching the docker marker's semantics.
- Drop the S3 metadata round-trip for `bundle_version` in
build-docker.yml; compute it locally with `git describe`, same as
build-bundle.yml (requires fetch-depth: 0 on that checkout).
- Split `promote` into two mutually-exclusive jobs, `promote` (needs
`build` to succeed) and `retag` (needs only `prepare`, runs when
`prepare.outputs.exists == 'true'`), each moving the `:<gh_ref>`
branch tags to the current sha. This replaces relying on `build`'s
skip/success state with two explicit conditions, so the tags always
get moved regardless of which path built the images.
Signed-off-by: David Barragán Merino <david.barragan@kaleidos.net>
The notify steps referenced mattermost/action-mattermost-notify@master, a
mutable branch that runs in CI with access to the MATTERMOST_WEBHOOK_URL
secret. Pinning to the immutable commit of the latest release (v2.1.0,
ae31bb6) keeps the exact reviewed code from executing, per GitHub third-party
action hardening guidance, while staying easy to bump.
