diff --git a/.github/workflows/docker.yml b/.github/workflows/docker.yml index 793568d0b5..adaef6e7b5 100644 --- a/.github/workflows/docker.yml +++ b/.github/workflows/docker.yml @@ -20,7 +20,13 @@ permissions: # Serialise builds per ref without killing an in-flight one: a newer push # supersedes only the pending slot, so the image build that is already -# running always finishes and publishes. +# running always finishes and publishes. Canary TAG refs each get their +# own group on purpose: their builds run in parallel so every published +# canary gets its sha images regardless of merge cadence. The mutable +# `:canary` channel tags are NOT written by the build matrix (which +# would race across parallel runs) — each canary-tag run retags the +# channel afterwards, only if it still matches the npm `canary` +# dist-tag, so the channel moves monotonically and always mirrors npm. concurrency: group: docker-${{ github.ref }} cancel-in-progress: false @@ -150,16 +156,18 @@ jobs: echo "last=${last}" >> "$GITHUB_OUTPUT" echo "count=${count}" >> "$GITHUB_OUTPUT" - # Lane tag mapping: master pushes publish `:canary`, nightly/v* tags - # publish `:nightly`, and only stable v* tags move `:latest` and the - # versioned tags. `:sha-` is published on every build. + # Lane tag mapping: nightly/v* tags publish `:nightly`, and only + # stable v* tags move `:latest` and the versioned tags. + # `:sha-` is published on every build. `:canary` is + # deliberately absent here — the channel tag is moved by the + # dist-tag-checked retag step below, never by the build matrix, + # so parallel canary builds cannot race it backwards. - name: Docker meta id: meta uses: docker/metadata-action@v6 with: images: ghcr.io/${{ github.repository }} tags: | - type=raw,value=canary,enable=${{ github.ref == 'refs/heads/master' }} type=raw,value=nightly,enable=${{ startsWith(github.ref, 'refs/tags/nightly/v') }} type=raw,value=beta,enable=${{ startsWith(github.ref, 'refs/tags/beta/v') }} type=raw,value=latest,enable=${{ startsWith(github.ref, 'refs/tags/v') }} @@ -201,6 +209,7 @@ jobs: # build: the step above is multi-arch with `push: true`, so nothing is # loaded into the runner's daemon. The cloud variant is FROM production # and inherits the same ENTRYPOINT, so checking this image covers both. + - name: Verify PID 1 reaps orphaned processes env: # Through the environment, not interpolated into the script body, so @@ -345,8 +354,9 @@ jobs: echo "count=${count}" >> "$GITHUB_OUTPUT" # Published under the same lane tag set as the self-hosted image, with a - # `-cloud` suffix (canary-cloud, nightly-cloud, latest-cloud, - # -cloud, sha--cloud). + # `-cloud` suffix (nightly-cloud, latest-cloud, -cloud, + # sha--cloud). `:canary-cloud` follows the same retag-step + # ownership rule as `:canary` above. - name: Docker meta (cloud) id: meta-cloud uses: docker/metadata-action@v6 @@ -355,7 +365,6 @@ jobs: flavor: | suffix=-cloud,onlatest=true tags: | - type=raw,value=canary,enable=${{ github.ref == 'refs/heads/master' }} type=raw,value=nightly,enable=${{ startsWith(github.ref, 'refs/tags/nightly/v') }} type=raw,value=beta,enable=${{ startsWith(github.ref, 'refs/tags/beta/v') }} type=raw,value=latest,enable=${{ startsWith(github.ref, 'refs/tags/v') }} @@ -401,6 +410,7 @@ jobs: # module resolution walks. Verify the image this job just pushed, not # a local build, so a build-cache or layer-ordering regression is # caught before any tenant runs the image. + - name: Verify the pushed image resolves the declared Sentry version env: IMAGE_TAGS: ${{ steps.meta-cloud.outputs.tags }} @@ -423,3 +433,58 @@ jobs: exit 1 fi echo "The pushed image resolves the declared @sentry/node version." + + # Moves the mutable `:canary` / `:canary-cloud` channel tags. Kept OUT + # of the build jobs and serialized in its own lane, and — the load- + # bearing property — CONVERGENT rather than self-interested: a + # promotion does not promote "its own" canary, it retags the channel + # to whatever the npm `canary` dist-tag names at execution time, + # provided that version's sha images are published. GitHub's shared + # concurrency lane keeps one running and one pending promotion and + # REPLACES the pending slot with the latest enqueued — an older build + # finishing late can therefore evict the newest canary's pending + # promotion. With convergent promotion that eviction is harmless: + # whichever promotion survives resolves the current dist-tag fresh + # and lands the channel there (the current canary's images always + # exist by the time any later promotion runs, because per-tag build + # groups mean canary builds are never superseded and each run's + # promotion is gated on its own completed pushes). Every interleaving + # converges the Docker channel onto the npm channel. + promote_canary_channel: + if: startsWith(github.ref, 'refs/tags/canary/v') + needs: [build-and-push, build-and-push-cloud] + runs-on: ubuntu-latest + timeout-minutes: 10 + permissions: + contents: read + packages: write + concurrency: + group: docker-canary-channel-promotion + cancel-in-progress: false + steps: + - name: Login to GitHub Container Registry + uses: docker/login-action@v4 + with: + registry: ghcr.io + username: ${{ github.repository_owner }} + password: ${{ secrets.GITHUB_TOKEN }} + + - name: Converge the channel tags onto the current npm canary + env: + IMAGE: ghcr.io/${{ github.repository }} + GH_TOKEN: ${{ github.token }} + run: | + current="$(curl -fsS "https://registry.npmjs.org/-/package/@paperclipai%2Fdb/dist-tags" | jq -er .canary)" + sha="$(gh api "repos/${GITHUB_REPOSITORY}/commits/$(printf 'canary/v%s' "$current" | jq -sRr @uri)" --jq .sha 2>/dev/null || true)" + if [ -z "$sha" ]; then + echo "canary/v${current} does not resolve yet; a later promotion converges the channel" + exit 0 + fi + short="$(printf '%s' "$sha" | cut -c1-7)" + if ! docker buildx imagetools inspect "$IMAGE:sha-${short}-cloud" >/dev/null 2>&1; then + echo "images for ${current} (sha-${short}) not published yet; its own promotion converges the channel" + exit 0 + fi + docker buildx imagetools create -t "$IMAGE:canary" "$IMAGE:sha-${short}" + docker buildx imagetools create -t "$IMAGE:canary-cloud" "$IMAGE:sha-${short}-cloud" + echo "channel tags moved to canary ${current} (sha-${short})" diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 49c00e59fd..4edc35b836 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -304,6 +304,8 @@ jobs: permissions: contents: write id-token: write + # For the explicit docker.yml dispatch below. + actions: write steps: - name: Checkout repository @@ -362,6 +364,29 @@ jobs: git push origin "refs/tags/${tag}" echo "version=${tag#canary/v}" >> "$GITHUB_OUTPUT" + # Canary images previously relied on the master-push docker.yml run, + # whose single pending concurrency slot gets superseded by every + # newer push — on a busy day no canary image publishes at all (five + # consecutive canaries shipped npm packages with no cloud image on + # 2026-09-06, starving downstream managed deploys for ~18 hours). + # Tag pushes made with GITHUB_TOKEN do not fire docker.yml's + # triggers, so dispatch the image build at the canary tag + # explicitly, exactly like the nightly and beta lanes: the run keys + # its concurrency off the tag ref, so no master push can supersede + # it, and docker.yml's `type=sha` mapping publishes the + # sha- and sha--cloud images either way. + - name: Build Docker images for the canary tag + env: + GH_TOKEN: ${{ github.token }} + run: | + { + echo "## Canary published" + echo "" + echo "- Published canary: \`${{ steps.canary_tag.outputs.version }}\`" + echo "- Docker build dispatched at \`canary/v${{ steps.canary_tag.outputs.version }}\`" + } >> "$GITHUB_STEP_SUMMARY" + gh workflow run docker.yml --ref "refs/tags/canary/v${{ steps.canary_tag.outputs.version }}" --repo "$GITHUB_REPOSITORY" + # The package is already public when this gate runs. A red result leaves the # immutable canary in npm, but makes the release workflow visibly fail before # anyone mistakes an installable package for an onboardable one.