Aggregate impact uses a stale base when GitHub's pull_request.base.sha lags #2524

Problem

.github/workflows/aggregate-impact.yaml takes the base commit from github.event.pull_request.base.sha (PR_BASE). Its own comment says the head is the test-merge commit "whose first parent is the base". GitHub does not keep those two in step: base.sha can lag behind the commit the merge was actually built on.

On #2433, run 39254756704:

• PR_BASE was 62a0117f9a.
• The head, merge commit e4ed1f6d1b, has first parent 7726c1a176, which is 87 commits ahead of 62a0117f9a.
• The base measurement crashed with KeyError: 'war_widows_pension', so the job failed with "The base measurement crashed". The measurement tool, copied from the head, reads war_widows_pension, which 62a0117f9a predates and 7726c1a176 has. So the true base would not have hit this error.

The comparison was between the merge result and an older main, not between the merge result and the main it was merged with. Re-running the job reuses the same event payload, so it checks out the same stale base and fails the same way.

#2506 tightens the runtime identity check in compare.py (#2499). It does not change how the base commit is chosen, so it does not fix this.

Proposed fix

For pull_request events, take the base from the checked-out merge commit itself:

• check out the head with fetch-depth: 2;
• set the base to git rev-parse HEAD^1 in the head checkout, and check that out as the base;
• keep PR_BASE only for the report label, or log a notice when it differs from HEAD^1.

Then the base is, by construction, the commit the merge was built on, and a re-run measures the right pair.

🤖 Generated with Claude Code