Skip to content

ci: validate intra-repo module pins are reachable from the default branch#630

Draft
nadahalli wants to merge 1 commit into
mainfrom
tejaswi/validate-intra-module-refs
Draft

ci: validate intra-repo module pins are reachable from the default branch#630
nadahalli wants to merge 1 commit into
mainfrom
tejaswi/validate-intra-module-refs

Conversation

@nadahalli

Copy link
Copy Markdown

What

Adds a required check that every intra-repo module pin
(github.com/smartcontractkit/capabilities/* required by another module via
pseudo-version) resolves to a commit reachable from the default branch.

  • script/validate-intra-module-refs.sh: greps every go.mod for
    capabilities/* pseudo-version pins, extracts the SHA, and asserts
    git merge-base --is-ancestor <sha> origin/main.
  • make validate-module-refs target.
  • A validate-module-refs CI job, added to the checks gate.

Why

This is a multi-module monorepo: chain_capabilities/{evm,solana,aptos}
require libs and chain_capabilities/common by pseudo-version, with no
replace directives. So a pinned SHA must live on the default branch, or
external consumers and fresh builds here fail with "unknown revision".

A consumer was pinned to a libs commit (c4b42d8) that only ever lived on
a feature branch. Once that branch was gone and the commit was GC'd, every
downstream build broke: chainlink image builds (it installs these as LOOPP
plugins) and fresh builds in this repo. Builds that ran while the commit
still existed were stale-green, so nothing surfaced it until much later.
This check catches that class at PR time, while the off-default-branch pin
is still resolvable.

Pairs with make update-common-capabilities, which should only ever target
a commit already merged to the default branch.

Verified

  • Passes on current main (6 intra-repo pins, all reachable).
  • Re-introducing the c4b42d8 pin makes it fail with a clear message (exit 1).

…anch

This monorepo's modules require sibling modules (chain_capabilities/* ->
libs, -> chain_capabilities/common) by pseudo-version, with no replace
directives, so a pinned SHA must live on the default branch or external
consumers and fresh builds break with "unknown revision".

A consumer was pinned to a libs commit (c4b42d8) that was only ever on a
feature branch; once it was GC'd, every downstream build (chainlink image
builds, this repo's fresh builds) failed to resolve it. Builds that ran
while the commit still existed were stale-green, so nothing flagged it.

Add script/validate-intra-module-refs.sh (greps every go.mod for
capabilities/* pseudo-version pins and asserts each SHA is reachable from
the default branch), a `make validate-module-refs` target, and a required
CI job wired into the checks gate. Pair it with
`make update-common-capabilities`, which must only target merged commits.
@github-actions

github-actions Bot commented Jun 2, 2026

Copy link
Copy Markdown

👋 nadahalli, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!

@cl-sonarqube-production

Copy link
Copy Markdown

Quality Gate passed Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

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