Skip to content

Add CI check that no submodule pin regresses relative to main#3331

Open
jgmelber wants to merge 3 commits into
Xilinx:mainfrom
jgmelber:ci/check-aie-api-submodule-pin
Open

Add CI check that no submodule pin regresses relative to main#3331
jgmelber wants to merge 3 commits into
Xilinx:mainfrom
jgmelber:ci/check-aie-api-submodule-pin

Conversation

@jgmelber

@jgmelber jgmelber commented Jul 13, 2026

Copy link
Copy Markdown
Collaborator

Summary

Stacked on top of #3330 — this branch is based on fix/aie-api-submodule-pointer, so its CI runs against the corrected pin. It'll show as behind main until #3330 merges; merge order: #3330 first, then this.

third_party/aie_api's pin has been silently reverted to a stale, divergent pre-#3262 commit twice by a merge/rebase from a branch based before a prior fix landed — first fixed by #3292, then it regressed again via #3296 (fixed by #3330). Nothing stops this from happening to any submodule, not just aie_api.

This adds a Lint and Format job, submodule-regressions, generalized across every submodule in .gitmodules (cmake/modulesXilinx, platforms/boards, third_party/aie-rt, third_party/bootgen, third_party/aie_api):

Test plan

  • Ran utils/check_submodule_regressions.py against the live repo (before Fix aie_api submodule pointer accidentally reverted by #3296 #3330 merges): correctly flags third_party/aie_api's still-live regression, correctly reports the other four submodules unchanged
  • Built a synthetic submodule + superproject sandbox and verified all three branches of the logic directly:
    • forward pin bump → passes
    • .gitmodules url changed alongside a non-ff pin change → skipped
    • pin silently reverted (no url change) → fails with exit 1
  • Validated the modified lintAndFormat.yml parses as YAML

🤖 Generated with Claude Code

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

Adds a CI guard to prevent third_party/aie_api (which should track Xilinx/aie_api) from silently regressing to a stale/divergent submodule commit during merges/rebases.

Changes:

  • Introduces utils/check_aie_api_submodule.py to verify the pinned submodule commit is an ancestor of upstream’s default branch.
  • Adds a new aie-api-submodule job to the existing “Lint and Format” workflow to run that check in CI.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File Description
utils/check_aie_api_submodule.py New Python check that fetches upstream refs and validates the submodule pin is on upstream history.
.github/workflows/lintAndFormat.yml Adds a CI job to run the new submodule-pin reachability check.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread utils/check_aie_api_submodule.py Outdated
Comment thread utils/check_aie_api_submodule.py Outdated
@jgmelber jgmelber changed the title Add CI check for aie_api submodule pin regressing to a stale commit Add CI check that no submodule pin regresses relative to main Jul 13, 2026
@jgmelber

Copy link
Copy Markdown
Collaborator Author

Addressed the two Copilot review comments (both resolved) — see inline replies for details:

  • The url-changed path no longer silently skips the ancestry check; it now validates against the new url and fails if it's not a genuine fast-forward.
  • Fetch failures now produce a clear ::error:: instead of an unhandled traceback, and the ancestry fetches use --filter=blob:none --no-tags.

Also fixed the Check code format (black) failure from the earlier push — all lint/format checks are green now.

The one remaining red check, Submodule pins haven't regressed, is expected: this branch is stacked on #3330, and CI here still compares against real origin/main, which hasn't picked up #3330's fix yet. It'll go green once #3330 merges and this branch rebases (or once the PRs are merged in order).

jgmelber and others added 3 commits July 13, 2026 16:21
third_party/aie_api tracks stock upstream Xilinx/aie_api directly (no
fork, see Xilinx#3262), after the local ADF-header patch was replaced by a
compile-time define. The pin has since been silently reverted to a
stale, divergent pre-Xilinx#3262 commit twice by a merge/rebase from a branch
based before the fix landed (Xilinx#3292, Xilinx#3330's regression from Xilinx#3296).

Add a CI job that fetches the pin and upstream's default branch tip
directly from the submodule's own remote and fails if the pin is not
an ancestor of upstream main, catching a third recurrence at PR time
instead of after merge.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replace the aie_api-specific "must be an ancestor of upstream main" check
with a generic ratchet: for every submodule in .gitmodules, HEAD's pin
must be unchanged or a descendant of origin/main's pin. This needs no
per-submodule knowledge of which branch/tag it tracks (cmake/modulesXilinx,
platforms/boards, third_party/aie-rt, and third_party/bootgen each track
a different one), so it generalizes cleanly across all five submodules
instead of just the one that has regressed twice so far.

A submodule whose .gitmodules url changes in the same diff is skipped,
since a deliberate remote switch (see Xilinx#3262) can legitimately be a
non-fast-forward change, and the url edit is itself a visible, reviewed
part of the diff.

Verified locally against a synthetic submodule+superproject: forward
bumps pass, url switches are skipped, and a reverted pin is caught with
exit 1.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two issues Copilot flagged on the earlier aie_api-only version of this
check still applied to the generalized version:

- A submodule whose .gitmodules url changed was unconditionally skipped,
  meaning a bad merge that regresses both the pin and the url together
  (reverting back to an old fork, say) would silently pass. Now the
  ancestry check runs against the *new* url instead of being skipped;
  it only passes if the new pin is provably a descendant of the old one
  there. A genuine non-fast-forward remote switch still fails and must
  be landed explicitly (e.g. an admin merge), rather than passing
  silently just because "the url changed".

- git fetch failures (e.g. a pin that's unreachable from any ref on the
  remote) surfaced as an unhandled CalledProcessError traceback instead
  of a clear ::error:: message. Fetches now go through a non-raising
  helper and a failed fetch is reported as "not reachable at all".

Also pass --filter=blob:none --no-tags on the ancestry-check fetches,
since they only need commit/tree objects.

Verified against three new synthetic sandbox cases: url switch to a
provably unrelated remote now fails instead of silently passing, and a
genuine fast-forward across a url switch (the Xilinx#3262 pattern) still
passes with a note.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@jgmelber jgmelber force-pushed the ci/check-aie-api-submodule-pin branch from 9c5695f to 48583c6 Compare July 13, 2026 22:21

@andrej andrej left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Good addition. The only question I have is if there is a way to circumvent this if we for some reason ever realize we need to roll back a submodule? I guess we could just accept the red X once and bypass the check which would be fine since that seems like a rare occurence.

@jgmelber

Copy link
Copy Markdown
Collaborator Author

Good addition. The only question I have is if there is a way to circumvent this if we for some reason ever realize we need to roll back a submodule? I guess we could just accept the red X once and bypass the check which would be fine since that seems like a rare occurence.

That's one of my hesitations for including this...is it really all that necessary or helpful?

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