Skip to content

ci: add optional ipfs_hash input to staker test reusable workflows - #4

Merged
3alpha merged 1 commit into
masterfrom
ci/ipfs-hash-input
Jun 24, 2026
Merged

ci: add optional ipfs_hash input to staker test reusable workflows#4
3alpha merged 1 commit into
masterfrom
ci/ipfs-hash-input

Conversation

@3alpha

@3alpha 3alpha commented Jun 24, 2026

Copy link
Copy Markdown
Member

Adds an optional ipfs_hash input to staking-sync-test.yml and staking-attestation-test.yml.

Behavior

  • Wrapper passes a pre-built IPFS hash (via repository_dispatch client_payload or workflow_dispatch input) → the test job prefers it over the freshly built hash.
  • No input → behavior is unchanged (build job still runs and its hash is used).

Why
Wrappers in the 10 staker package repos are about to forward an ipfs_hash from TropiBot's dispatch payload. The reusable workflows need to accept that input. The build job is kept always-on for now; a follow-up can short-circuit it when an input hash is present.

Adds a new optional 'ipfs_hash' input to staking-sync-test and
staking-attestation-test. When the wrapper passes a pre-built IPFS hash
(via repository_dispatch client_payload or workflow_dispatch input), the
test job prefers it over the freshly built hash from the build job. When
no input is provided, behavior is unchanged: the build job still runs and
its hash is used.

The build job is intentionally kept always-on for now; this is purely
forward-looking plumbing so the wrappers can forward the dispatch
payload's ipfs_hash. A future change can short-circuit the build job
when an input hash is present.
@3alpha
3alpha merged commit d0d93c4 into master Jun 24, 2026
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.

1 participant