jerry/buzz - buzz - Gitea: Git with a cup of tea

jerry/buzz

Fork 0

mirror of https://github.com/block/buzz.git synced 2026-10-29 05:21:31 +00:00

Commit Graph

Author	SHA1	Message	Date
Luke Tornquist	99c5fc8bba	ci(docker): publish qualified, sortable push gateway main tags (#8305 ) ## Summary This PR makes two changes to the push gateway image job (`push-gateway-merge` in `docker.yml`). Together they let staging auto-promote the gateway the same way it already auto-promotes the relay: 1. Publish only after same-SHA CI qualification. `push-gateway-merge` now needs `qualify` as well as `push-gateway-build`. This is the same gate the relay's `merge` job already uses: a successful `ci.yml` push run on the exact source SHA. Before this change, the gateway image was published even when main CI was red. That was safe while staging pinned the gateway by hand. It isn't safe once the newest main image deploys automatically. 2. Publish the sortable `:main-<YYYYMMDDHHmmss>-<sha7>` tag on main pushes. It's the same `type=raw` line the relay matrix gained in #8240. It uses the same `enable=` guard, so it applies only to `push` on `refs/heads/main`. A Lexical selector on `^main-\d{14}-[0-9a-f]{7}$` can then pick the newest gateway build from the tag list alone. `:sha-<7>` has no ordering. `:main`, `:sha-<7>`, and the release semver tags don't change. The gateway has no debug variant, so no `debug-main-` tag is published. Tradeoff:* a gateway image now appears only after `qualify` finishes, which takes as long as main CI. If main CI fails, no gateway image is published for that commit, and that includes `:main` and `:sha-<7>`. The relay already behaves this way, and it's the behavior we want for anything that auto-deploys. What got simpler: the relay and gateway images now share the same publication gate and the same tag set. Downstream tooling no longer needs a special case for the gateway's unqualified, unordered tags. What stays different: the relay's `merge` job also attests the `deployment-eligibility/v1` predicate (`docs/deployment-identity.md`); the gateway publishes no such attestation. That's intentional for now: the staging promotion guard selects the gateway by package and `main-` tag and does not verify attestations, so the gateway warehouse must not be wired to require one. If promotion ever starts verifying eligibility, the gateway needs the same attestation first. ### Related issue N/A (staging rollout tooling). The downstream promotion-guard and warehouse changes land separately. The warehouse switches on only after this tag has been published. ### Testing - `scripts/test-relay-image-eligibility-workflow.sh` now pins both properties of the `push-gateway-merge` job (it runs in CI under "Relay image eligibility contract"). Both checks match whole active lines, so a commented-out copy can't satisfy them. - At `9b8c49600` it passes. - With the live `needs` line replaced by `needs: [push-gateway-build]` and a commented-out `# needs: [push-gateway-build, qualify]` left behind, it fails. - With the gateway `main-` line commented out, it fails. - With `needs` reverted to `push-gateway-build`, it fails with `push gateway image must publish only after same-SHA CI qualification`. - With the `main-` tag line removed, it fails with `push gateway image must publish the sortable main-<commit UTC>-<7> tag on main pushes`. - `scripts/test-release-ref-contract.sh` now counts the sortable `main-` tag line on all three image legs (relay, relay-debug, gateway) instead of two. It passes at `9b8c49600`. - `bin/actionlint .github/workflows/docker.yml` is clean at `f6c03b6b5`. - PR runs don't push images. The first real `main-*` gateway tag appears on the first main push after merge, and I'll check the registry for it on that manifest. --------- Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>	2026-10-14 14:36:00 -04:00
Will Pfleger	cae7f826b3	fix(ci): check out source in docker.yml merge job (#6833 ) ## Problem Every `docker.yml` run on `main` has failed since [#6781](https://github.com/block/buzz/pull/6781) merged. That PR added a "Create deployment eligibility predicate" step to the `merge` job, which runs `jq` against `$GITHUB_WORKSPACE/scripts/create-deployment-eligibility-predicate.jq`. But the `merge` job has no `actions/checkout` step — the workspace is empty, so `jq` can't open the file and exits `2` (`jq: Could not open ... No such file or directory`). The `build` and `qualify` jobs each check out the source; `merge` never needed one until this step was added. ## Fix - `.github/workflows/docker.yml`: add `actions/checkout` (same pinned SHA as the other jobs, `df4cb1c` / v6.0.3) as the first step of the `merge` job. - `scripts/test-relay-image-eligibility-workflow.sh`: guard the regression by asserting the `merge` job checks out the source before building the predicate. ## Verification CI cannot exercise the `merge` job on a pull request — the job is gated `if: github.event_name != 'pull_request'`, so it only runs on push to `main`. The proof is the root cause (missing checkout for a step that reads a repo file) plus the eligibility workflow test: `scripts/test-relay-image-eligibility-workflow.sh` passes with the fix and fails with the new guard's specific message (`merge job must check out the source before building the eligibility predicate`) when the checkout is removed. Signed-off-by: Will Pfleger <pfleger.will@gmail.com>	2026-08-25 18:50:47 -04:00
Luke Tornquist	f249710331	Qualify canonical relay images for staged delivery (#6781 ) ## Why Phase 1 of progressive delivery needs an explicit eligibility boundary before deployment automation can safely consume relay artifacts. Today the canonical Docker workflow can publish independently of the same-SHA CI result, the relay does not expose its source/build identity, and the Helm chart only renders mutable tags. The existing `ghcr.io/block/buzz-staging-dev` workflow in #6709 remains a manual pre-merge preview lane. It is deliberately not a canonical promotion input. ## What changed - Compile the full source SHA and GitHub Actions build identity into canonical relay binaries and expose it at `/_status`. - Gate creation of tagged multi-architecture manifests on the latest exact-SHA `CI` push run succeeding on `main` or `release`. - Preserve the signed SLSA provenance and add a signed, release-only deployment-eligibility predicate with source, build run, qualifying CI run, and exact compatible Buzz chart version. - Keep failed or pending builds untagged and without an eligibility predicate; preview-package artifacts are excluded by package and signer contract. - Add optional `image.digest` support to Buzz chart `0.1.8`, retaining the existing tag fallback. - Document verification and the intentional boundary between image/chart compatibility and backwards-compatible database migrations. ## Risk and rollout Canonical tag publication now waits for same-SHA CI and fails closed when the newest matching run fails. Per-architecture blobs may remain untagged after a failed qualification; they are not promotion inputs. Debug manifests are also CI-gated but do not receive the release eligibility predicate. There are no migration or schema-orchestration changes. The companion BuilderBot infrastructure PR will pin a separately verified canonical main digest and expose a read-only running-deployment inspection command. Signed eligibility is available only for artifacts published after this workflow lands. ## Verification - Blox: workflow contract fixtures, including stale-green rejection and predicate structure - Blox: `actionlint` for `ci.yml` and `docker.yml` - Blox: 46 Helm unit tests, chart lint, and production/quickstart render fixtures - Blox: relay status unit test, workspace Rust formatting, and workspace all-target clippy - Live evidence: exact-SHA CI selector chose successful run `32857345153` for source `9d1e4b257657f382d3111ce748f3da8d063b7671` - Existing canonical digest provenance verified with `gh attestation verify` ## References - #6709 — developer-preview precursor; intentionally separate from canonical eligibility - `docs/deployment-identity.md` Generated with Codex --------- Signed-off-by: Luke Tornquist <tornquist@squareup.com>	2026-08-25 14:44:49 -04:00

Author

SHA1

Message

Date

Luke Tornquist

99c5fc8bba

ci(docker): publish qualified, sortable push gateway main tags (#8305 )

## Summary

This PR makes two changes to the push gateway image job
(`push-gateway-merge` in `docker.yml`). Together they let staging
auto-promote the gateway the same way it already auto-promotes the
relay:

1. **Publish only after same-SHA CI qualification.**
`push-gateway-merge` now needs `qualify` as well as
`push-gateway-build`. This is the same gate the relay's `merge` job
already uses: a successful `ci.yml` push run on the exact source SHA.
Before this change, the gateway image was published even when main CI
was red. That was safe while staging pinned the gateway by hand. It
isn't safe once the newest main image deploys automatically.
2. **Publish the sortable `:main-<YYYYMMDDHHmmss>-<sha7>` tag on main
pushes.** It's the same `type=raw` line the relay matrix gained in
#8240. It uses the same `enable=` guard, so it applies only to `push` on
`refs/heads/main`. A Lexical selector on `^main-\d{14}-[0-9a-f]{7}$` can
then pick the newest gateway build from the tag list alone. `:sha-<7>`
has no ordering.

`:main`, `:sha-<7>`, and the release semver tags don't change. The
gateway has no debug variant, so no `debug-main-*` tag is published.

**Tradeoff:** a gateway image now appears only after `qualify` finishes,
which takes as long as main CI. If main CI fails, no gateway image is
published for that commit, and that includes `:main` and `:sha-<7>`. The
relay already behaves this way, and it's the behavior we want for
anything that auto-deploys.

**What got simpler:** the relay and gateway images now share the same
publication gate and the same tag set. Downstream tooling no longer
needs a special case for the gateway's unqualified, unordered tags.

**What stays different:** the relay's `merge` job also attests the
`deployment-eligibility/v1` predicate (`docs/deployment-identity.md`);
the gateway publishes no such attestation. That's intentional for now:
the staging promotion guard selects the gateway by package and `main-*`
tag and does not verify attestations, so the gateway warehouse must not
be wired to require one. If promotion ever starts verifying eligibility,
the gateway needs the same attestation first.

### Related issue

N/A (staging rollout tooling). The downstream promotion-guard and
warehouse changes land separately. The warehouse switches on only after
this tag has been published.

### Testing

- `scripts/test-relay-image-eligibility-workflow.sh` now pins both
properties of the `push-gateway-merge` job (it runs in CI under "Relay
image eligibility contract"). Both checks match whole active lines, so a
commented-out copy can't satisfy them.
- At `9b8c49600` it passes.
- With the live `needs` line replaced by `needs: [push-gateway-build]`
and a commented-out `# needs: [push-gateway-build, qualify]` left
behind, it fails.
- With the gateway `main-*` line commented out, it fails.
- With `needs` reverted to `push-gateway-build`, it fails with `push
gateway image must publish only after same-SHA CI qualification`.
- With the `main-*` tag line removed, it fails with `push gateway image
must publish the sortable main-<commit UTC>-<7> tag on main pushes`.
- `scripts/test-release-ref-contract.sh` now counts the sortable
`main-*` tag line on all three image legs (relay, relay-debug, gateway)
instead of two. It passes at `9b8c49600`.
- `bin/actionlint .github/workflows/docker.yml` is clean at `f6c03b6b5`.
- PR runs don't push images. The first real `main-*` gateway tag appears
on the first main push after merge, and I'll check the registry for it
on that manifest.

---------

Signed-off-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>
Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz>

2026-10-14 14:36:00 -04:00

Will Pfleger

cae7f826b3

fix(ci): check out source in docker.yml merge job (#6833 )

## Problem

Every `docker.yml` run on `main` has failed since
[#6781](https://github.com/block/buzz/pull/6781) merged. That PR added a
"Create deployment eligibility predicate" step to the `merge` job, which
runs `jq` against
`$GITHUB_WORKSPACE/scripts/create-deployment-eligibility-predicate.jq`.
But the `merge` job has no `actions/checkout` step — the workspace is
empty, so `jq` can't open the file and exits `2` (`jq: Could not open
... No such file or directory`). The `build` and `qualify` jobs each
check out the source; `merge` never needed one until this step was
added.

## Fix

- `.github/workflows/docker.yml`: add `actions/checkout` (same pinned
SHA as the other jobs, `df4cb1c` / v6.0.3) as the first step of the
`merge` job.
- `scripts/test-relay-image-eligibility-workflow.sh`: guard the
regression by asserting the `merge` job checks out the source before
building the predicate.

## Verification

CI cannot exercise the `merge` job on a pull request — the job is gated
`if: github.event_name != 'pull_request'`, so it only runs on push to
`main`. The proof is the root cause (missing checkout for a step that
reads a repo file) plus the eligibility workflow test:
`scripts/test-relay-image-eligibility-workflow.sh` passes with the fix
and fails with the new guard's specific message (`merge job must check
out the source before building the eligibility predicate`) when the
checkout is removed.

Signed-off-by: Will Pfleger <pfleger.will@gmail.com>

2026-08-25 18:50:47 -04:00

Luke Tornquist

f249710331

Qualify canonical relay images for staged delivery (#6781 )

## Why

Phase 1 of progressive delivery needs an explicit eligibility boundary
before deployment automation can safely consume relay artifacts. Today
the canonical Docker workflow can publish independently of the same-SHA
CI result, the relay does not expose its source/build identity, and the
Helm chart only renders mutable tags.

The existing `ghcr.io/block/buzz-staging-dev` workflow in #6709 remains
a manual pre-merge preview lane. It is deliberately not a canonical
promotion input.

## What changed

- Compile the full source SHA and GitHub Actions build identity into
canonical relay binaries and expose it at `/_status`.
- Gate creation of tagged multi-architecture manifests on the latest
exact-SHA `CI` push run succeeding on `main` or `release`.
- Preserve the signed SLSA provenance and add a signed, release-only
deployment-eligibility predicate with source, build run, qualifying CI
run, and exact compatible Buzz chart version.
- Keep failed or pending builds untagged and without an eligibility
predicate; preview-package artifacts are excluded by package and signer
contract.
- Add optional `image.digest` support to Buzz chart `0.1.8`, retaining
the existing tag fallback.
- Document verification and the intentional boundary between image/chart
compatibility and backwards-compatible database migrations.

## Risk and rollout

Canonical tag publication now waits for same-SHA CI and fails closed
when the newest matching run fails. Per-architecture blobs may remain
untagged after a failed qualification; they are not promotion inputs.
Debug manifests are also CI-gated but do not receive the release
eligibility predicate.

There are no migration or schema-orchestration changes. The companion
BuilderBot infrastructure PR will pin a separately verified canonical
main digest and expose a read-only running-deployment inspection
command. Signed eligibility is available only for artifacts published
after this workflow lands.

## Verification

- Blox: workflow contract fixtures, including stale-green rejection and
predicate structure
- Blox: `actionlint` for `ci.yml` and `docker.yml`
- Blox: 46 Helm unit tests, chart lint, and production/quickstart render
fixtures
- Blox: relay status unit test, workspace Rust formatting, and workspace
all-target clippy
- Live evidence: exact-SHA CI selector chose successful run
`32857345153` for source `9d1e4b257657f382d3111ce748f3da8d063b7671`
- Existing canonical digest provenance verified with `gh attestation
verify`

## References

- #6709 — developer-preview precursor; intentionally separate from
canonical eligibility
- `docs/deployment-identity.md`

*Generated with Codex*

---------

Signed-off-by: Luke Tornquist <tornquist@squareup.com>

2026-08-25 14:44:49 -04:00

3 Commits