Release v28.0.0 - #214
Conversation
Three issues raised on #213, fixed here rather than on the merge PR to avoid re-running the integration suite: - horizon-release.yml ran the deprecation egrep before actions/checkout, so it scanned an empty workspace and its negated exit always succeeded. Checkout now comes first (and moves to @v4, matching the rest of the repo). - release-readiness.yml still matched the pre-#202 PROTOCOL_<N>_STELLAR_RPC_DOCKER_IMG env-var shape, so it never inspected the lowercase stellar_rpc_docker_img inputs horizon.yml actually defines: an empty pin took the success path even when targeting main. It now matches the real key in both quote styles. - The 28.0.0 changelog entry claimed MaxSupportedProtocolVersion needed no bump, which was only true relative to protocol-next; 27.0.0 shipped 27. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Prepares Horizon v28.0.0 by correcting release safeguards and release documentation.
Changes:
- Runs deprecation checks after repository checkout.
- Validates actual
stellar_rpc_docker_imgworkflow inputs. - Corrects the Protocol 28 changelog entry.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
CHANGELOG.md |
Documents the protocol-version bump. |
.github/workflows/release-readiness.yml |
Fixes empty RPC image-pin detection. |
.github/workflows/horizon-release.yml |
Checks out source before deprecation scanning. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
go.yml ran 'go test -race -cover ./...' with no -timeout, inheriting Go's 10m per-package default. internal/ingest and internal/db2/history both hit it: TestCoreLCMIngestion walks ~856 LedgerCloseMeta fixtures (691 under InvokeHostFunctionTests), and although its sub-tests are parallel, each one provisions its own Postgres database and runs the full migration suite. Neither timeout was a hang -- both packages were still making progress when killed -- and the fixture corpus grows every protocol, so this sets per-package headroom rather than a tight fit. The integration suite already passes -timeout 75m explicitly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Added The
Neither is a hang — both were making progress — so this is a genuine budget problem, and the fixture corpus grows every protocol. Filed as a follow-up on the train issue: the durable fix is to stop re-migrating a fresh database per fixture in |
Release PR for horizon v28.0.0 — part of the Protocol 28 GA release train (stellar/go-stellar-sdk#5967).
Carries the three review findings from #213, deliberately landed here instead of on the merge PR to avoid re-running the ~1h integration suite:
horizon-release.yml— the deprecationegrepran beforeactions/checkout, scanning an empty workspace, so the negated exit always succeeded and the gate could never fail a release. Checkout moved ahead of it (and bumped to@v4).release-readiness.yml— the empty-pin gate still matched the pre-Decompose Horizon integration tests into a callable workflow #202PROTOCOL_<N>_STELLAR_RPC_DOCKER_IMGenv-var shape, so it never inspected the lowercasestellar_rpc_docker_imginputshorizon.ymlactually defines; an empty pin took the success path even when targetingmain. Now matches the real key in both quote styles — verified silent on the current file, and firing on'',"", bare, and whitespace-only values while still ignoring the commented-out leg.CHANGELOG.md— the 28.0.0 entry claimedMaxSupportedProtocolVersionneeded no bump; true only relative to protocol-next, since released 27.0.0 shipped 27.Once this merges, its merge commit on main is the tag target for
v28.0.0(convention: tags must be main-reachable).Note: CI legs still pin
stellar/unsafe-stellar-core:28.0.0-3486.2332980a1.jammy. The swap tostellar/stellar-coreis a separate pre-tag step, still blocked on that image publishing.🤖 Generated with Claude Code