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>
Move build-docker and build-docker-devenv jobs from penpot-extended-runner
to penpot-standar-runner, point tests-exporter at the canonical
penpot-extended-runner label instead of the stale penpot-runner-02 alias,
and switch build-tag/release notify jobs from ubuntu-24.04 to ubuntu-latest.
Signed-off-by: David Barragán Merino <david.barragan@kaleidos.net>
Replaces the content-hash build key (bundle_version + docker/images tree hash) used to tag and dedupe the backend/frontend/exporter/storybook/mcp image set with sha-<commit>, matching the scheme already used by admin-console, licenses-manager and payments across the org. The check→build→promote pattern with the S3 marker is unchanged; only the key used for the marker, the immutable tag and the local bundle cache filename moves from the composite build key to the git commit sha (the bundle cache now keys on bundle_version alone, which is what it actually caches). devenv is intentionally left out of this pass, it has no versioned tagging today.
Signed-off-by: David Barragán Merino <david.barragan@kaleidos.net>
Move Dockerfile.frontend, .backend, .exporter, .mcp and .storybook
under docker/images/ from ubuntu:26.04 / nginx-unprivileged / a
manual Node tarball install to Docker Hardened Images (Debian 13,
or Alpine for storybook). storybook and mcp get a true non-dev
runtime; frontend, backend and exporter keep the -dev tag as their
final image, since each needs a shell and/or package manager at
container runtime (nginx templating, fontforge/python3, and a
headless-browser stack, respectively).
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.
