ci(giga-1): publish a seid image on every push to giga-1

[bdchatham]

nightly-ecr.yml checks out a hardcoded ref: main — the step is even named
"Checkout main HEAD" — so it can never build giga-1 however it is invoked, and
ecr.yml is branch-filtered to main/release/**. giga-1 has no publishing
workflow at all. This adds one.

Land this first. It is the producer for
sei-protocol/platform#1707, which deploys these images to a new
4-validator giga-testnet chain on harbor. That PR's spec.image carries an
all-zero placeholder tag until a real giga1-* image exists.

What it publishes

One vanilla image per push to giga-1, tagged
giga1-<YYYYMMDDHHMMSS>-<sha7>, to the existing
189176372795.dkr.ecr.us-east-2.amazonaws.com/sei/sei-chain repository. Same
repository, so the platform Pod Identity grant needs no terraform change.

Decisions a reviewer should challenge

• Push-triggered, not cron. "Every new image deploys" means every commit,
  not one a day. concurrency: cancel-in-progress: true means a push during a
  build cancels it, so at most one build runs and the published tag is always
  the newest commit that finished.
• Timestamp, not <date>. Building on push puts more than one image in a
  day. The house (?P<date>[0-9]{8}) extract would tie, and a numerical
  ImagePolicy cannot break a tie. 14 decimal digits stay inside float64's
  exact-integer range, so the ordering is exact.
• giga1- prefix. The three nightly ImagePolicy patterns are anchored on
  nightly-, mock-nightly- and
  mock_chain_validation-mock_balances-nightly-, and they carry no branch
  identity. A bare nightly-<date>-<sha7> tag built from giga-1 would be
  selected by sei-chain-nightly and could bump the nightly release gate onto a
  giga-1 build. This prefix cannot match any of them.
• Vanilla only, no mock_balances. giga-testnet submits no transactions,
  so no sender needs funding, and mock_balances would mask the state-machine
  regressions the chain exists to catch. One variant also keeps the loop fast
  and ECR growth low.
• load then smoke then push. The tag only exists once seid version has
  run inside the built image, so Flux cannot deploy a binary that never started.
  One build, so the bytes smoked are the bytes published. It does not prove the
  chain reaches consensus — that gate is named as a follow-up in the platform PR.
• paths-ignore on markdown. A docs-only commit produces an identical
  binary under a new sha7. The new tag would roll all four validators and stop
  block production for the restart window.
• workflow_dispatch ref assertion. workflow_dispatch takes no branch
  filter, so a dispatch from another ref would publish a giga1- tag built from
  that ref and Flux would deploy it. The first step fails loudly rather than
  skipping green.

Verified

• actionlint .github/workflows/giga1-ecr.yml — clean.
• evm.http_enabled, evm.ws_enabled and state-store.ss-enable exist as
  dotted keys on this branch, and SetEVMConfigByMode /
  TestTheRenderedConfigStillDiscardsTheStateStoreRules confirm validator mode
  turns all three off. That is why the platform PR sets all three.
• giga_executor.enabled and occ_enabled both default to true in
  giga/executor/config, so the platform PR pins neither.

Not verified

The workflow has never run. The build, the ECR push and the smoke step are
untested until this merges and giga-1 takes a push, or someone dispatches it.

🤖 Generated with Claude Code

[cursor]

PR Summary

Medium Risk
Introduces automated container publishing to shared ECR that downstream Flux will deploy; mitigated by branch/ref checks and a pre-push binary smoke step, but the workflow is not yet proven in CI.

Overview
Adds a Giga-1 ECR GitHub Actions workflow so pushes to giga-1 (and manual dispatch) build and publish a vanilla sei/sei-chain image to the existing us-east-2 ECR repo.

Images are tagged giga1-<UTC timestamp>-<sha7> (distinct from nightly-* policies), with concurrency canceling overlapping runs, paths-ignore for markdown/docs-only commits, and a ref guard so dispatch cannot publish from non-giga-1 refs. The job checks out the pushed commit, assumes the shared gha IAM role, builds with Buildx and a giga1 registry cache, runs docker run … version before push, then writes a step summary for harbor giga-testnet (Flux).

^{Reviewed by Cursor Bugbot for commit bfb7870. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Sep 15, 2026, 1:25 PM

[seidroid]

Adds a new giga1-ecr.yml workflow that builds, smoke-tests and publishes one vanilla seid image per push to giga-1. The structure mirrors nightly-ecr.yml and the build-then-smoke-then-push ordering is sound; two non-blocking issues concern tag ordering on reruns and the markdown path filter.

Findings: 0 blocking | 2 non-blocking | 2 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• None at the file/PR level.
• 2 suggestion(s)/nit(s) flagged inline on specific lines.

[seidroid]

[suggestion] The timestamp comes from wall clock at build time, not from the commit, so the "newest tag = newest commit" invariant the header comment relies on does not survive a rerun. A GitHub re-run reuses the original commit and ref (so the Refuse a ref that is not giga-1 guard still passes) but executes date -u again, producing a tag that sorts above every tag published since — and the numerical ImagePolicy on the platform side would then roll giga-testnet back onto that older binary.

This is not hypothetical given cancel-in-progress: true: a build cancelled by a newer push is exactly the run an operator is most likely to hit "Re-run" on, and the commit it carries is by construction older than what is deployed.

Deriving the timestamp from the commit makes the tag a pure function of the commit, so a rerun republishes an identically-ordered (in fact identical) tag:

TS=$(git show -s --format=%cd --date=format-utc:%Y%m%d%H%M%S HEAD)

(If you prefer to keep wall-clock tagging, the alternative is rejecting a commit that is not the current tip of giga-1 before the push step.)

[seidroid]

[suggestion] '**/*.md' is not a reliable way to match repository-root markdown in a GitHub path filter: ** is documented as matching zero or more of any character, which leaves the / in the pattern needing a directory segment, and the documented idiom for "every .md file anywhere" is '**.md'. Root-level markdown is exactly what this repo churns (AGENTS.md, CLAUDE.md, README.md, CHANGELOG.md), so if the pattern does not cover them, a docs-only commit still publishes a tag and rolls all four validators — the case this filter exists to prevent.

'**.md' is unambiguous under either reading and is a strict superset of the current pattern.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1425d89. Configure here.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (giga-1@f72d8d8). Learn more about missing BASE report.

Additional details and impacted files

@@            Coverage Diff            @@
##             giga-1    #4175   +/-   ##
=========================================
  Coverage          ?   65.55%           
=========================================
  Files             ?     2081           
  Lines             ?   157563           
  Branches          ?        0           
=========================================
  Hits              ?   103289           
  Misses            ?    54133           
  Partials          ?      141           

Flag	Coverage Δ
sei-db	74.50% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bdchatham]

Both findings were right. d307165 fixes them.

Re-run ordering. The wall-clock tag did break the invariant the design
rests on, and cancel-in-progress: true makes a cancelled older run the
likeliest re-run target. The tag now derives its timestamp from the committer
date, so it is a pure function of the commit.

One correction to the suggested snippet: --date=format-utc:... is not a git
date mode. git 2.53 rejects it with "date format missing colon separator".
The working equivalent, which I checked, is:

TS=$(TZ=UTC0 git show -s --format=%cd --date=format-local:%Y%m%d%H%M%S HEAD)

It is UTC-normalised (cross-checked against --date=iso-strict, which reports
the committer's +02:00), identical across two invocations, and ordered
correctly against the parent commit. format-local plus TZ=UTC0 is what does
the normalising; plain format: would use each committer's own recorded
offset, which two committers in different zones could invert.

A re-run now recomputes the same tag, and the repository is IMMUTABLE, so the
push refuses it and the re-run goes red. That is the right direction — a red
re-run rather than a chain rolled backwards — and
clusters/harbor/giga-testnet/README.md records it.

Markdown filter. Correct, and it mattered: ** matches zero characters, so
'**/*.md' needs a leading slash and misses AGENTS.md, CLAUDE.md and
README.md, which is what this repo churns. Now '**.md'.

This workflow carries no comments by request, so both invariants live in the
consumer's README under "What the producer must keep true".