The gate holds on amd64, and both images release as 1.5.89

The gate calls hanzoai/ci [email protected] with linux-amd64 as the only
architecture that gates, and linux-arm64 as an advisory leg that runs and
reports without holding anything. The o11y pod is scheduled on amd64, and the
one shared arm64 node kept the release queued for hours behind other repos.

hanzo.yml states version 1.5.89. The two images' series had drifted apart
(o11y at 1.5.88, o11y-site at 1.5.82) and far ahead of the git tags (v1.5.75), so
a derived number differed per image and a git tag would have overwritten an
August image of the same name. imgver publishes the declared version once and
the next patch thereafter, for both images alike.

Co-authored-by: Hanzo Dev <[email protected]>
This commit is contained in:
zooqueen
2026-09-24 10:53:08 -07:00
co-authored by Hanzo Dev
parent a113a85375
commit 53905542ff
2 changed files with 17 additions and 5 deletions
+8 -1
View File
@@ -11,5 +11,12 @@ on:
workflow_dispatch:
jobs:
cicd:
uses: hanzoai/ci/.github/workflows/build.yml@v1
uses: hanzoai/ci/.github/workflows/build.yml@v1.0.117
with:
# Only linux-amd64 gates: the o11y pod runs on amd64 (nodeSelector
# kubernetes.io/arch: amd64), and the one arm64 node is shared with every
# other runner, so its leg queued for hours and held the release. arm64
# still runs and reports as the advisory leg, which nothing waits on.
test-runners: '["linux-amd64"]'
advisory-runners: '["linux-arm64"]'
secrets: inherit
+9 -4
View File
@@ -29,10 +29,15 @@
# from KMS (falling back to the org GH_PAT), which is the same BuildKit
# `gh_token` this Dockerfile already reads. Nothing had to be given up to fold.
#
# No `version:` key: this repo carries no package.json/VERSION for it to name,
# so bin/imgver derives the series from the highest semver already published for
# each image and adds a patch — 1.5.63 -> 1.5.64 — which is the numbering the
# v1.5.x tags already follow. A release tag still publishes itself verbatim.
# `version:` names the release both images publish. bin/imgver publishes it
# verbatim when it is above what the registry holds, and the next patch of the
# registry's highest once it is not, so it is stated once and never needs
# chasing. It is stated at all because each image's series is its own: o11y had
# reached 1.5.88 and o11y-site 1.5.82 while the git tags stopped at v1.5.75, so
# derived numbers disagreed between the two images and a git tag — which
# publishes its own name verbatim, with nothing refusing an existing one — would
# have overwritten an August image of the same number. Release from main.
version: 1.5.89
images:
# The headless server (./cmd/community, O11Y_WEB_ENABLED=false). This is the