Skip to content

Release v28.0.0 - #214

Open
Shaptic wants to merge 4 commits into
mainfrom
release/v28.0.0
Open

Release v28.0.0#214
Shaptic wants to merge 4 commits into
mainfrom
release/v28.0.0

Conversation

@Shaptic

@Shaptic Shaptic commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

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:

  1. horizon-release.yml — the deprecation egrep ran before actions/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).
  2. release-readiness.yml — the empty-pin gate still matched the pre-Decompose Horizon integration tests into a callable workflow #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. 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.
  3. CHANGELOG.md — the 28.0.0 entry claimed MaxSupportedProtocolVersion needed 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 to stellar/stellar-core is a separate pre-tag step, still blocked on that image publishing.

🤖 Generated with Claude Code

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>
Copilot AI balanced review requested due to automatic review settings August 4, 2026 21:32

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_img workflow 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>
@Shaptic

Shaptic commented Aug 4, 2026

Copy link
Copy Markdown
Contributor Author

Added 644f6fc2: raises the unit-test timeout to -timeout 45m per package.

The test (ubuntu-24.04, 1.25, 16) failure was two packages hitting Go's 10m per-package default (the step passed no -timeout at all, unlike the integration suite's explicit -timeout 75m):

  • internal/ingestTestCoreLCMIngestion ran the full 10m and was still producing sub-tests when killed. It walks ~856 LedgerCloseMeta fixtures (691 under InvokeHostFunctionTests); sub-tests are t.Parallel(), but each provisions its own Postgres database and runs the whole migration suite.
  • internal/db2/history — cumulative package time exceeded 10m; the test running at the deadline (TestStreamAllOffersRequiresTx) was only 5s in.

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 TestCoreLCMIngestion, which would cut the bulk of that runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants