chore(size-limit-action): Resolve baseline by walking git history - #24310
Draft
mydea wants to merge 1 commit into
Draft
chore(size-limit-action): Resolve baseline by walking git history#24310mydea wants to merge 1 commit into
mydea wants to merge 1 commit into
Conversation
The size-limit GH action resolved the develop baseline from `listWorkflowRuns` filtered by branch + event. That listing is backed by an eventually-consistent index that can omit or reorder very recent runs, so the action would silently compare against a days-old baseline while still reporting it as the latest one (the `isLatest` flag was derived from `filtered[0]` of the same stale listing, so it could never detect the staleness it was meant to warn about). Drive baseline resolution from `repos.listCommits` (authoritative, strictly ordered git history) instead, and pin each candidate run by exact `head_sha`. Walking commits newest-first means the order is exact and, when the tip commit has no artifact yet, we fall back to its parent and correctly report the baseline as not-latest so the warning banner fires. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mydea
changed the title
Contributor
size-limit report 📦
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes 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 4022882. Configure here.
| } | ||
| core.warning(`No "${artifactName}" artifact found on branch "${branch}".`); | ||
| return null; | ||
| } |
There was a problem hiding this comment.
Fix PR missing regression tests
Medium Severity
This fix PR adds no unit, integration, or E2E test for the stale-baseline regression. Flagged because the review rules file asks for a test that fails without the change and passes with it, so the listCommits walk, head_sha pinning, and truthful isLatest behavior are covered.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 4022882. Configure here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The size-limit GitHub action was comparing PRs against a stale develop baseline — e.g. #24299 (run at 12:10 on Sep 10) picked a baseline build from Sep 8, two days and many commits behind the tip, without the "not the latest" warning banner.
Root cause
Baseline resolution drove off
listWorkflowRunsfiltered bybranch+event=push. That listing is backed by an eventually-consistent index that can omit or reorder recent runs. At the time #24299 ran, that index returned the Sep 8 run as the first (newest) result even though six completed Sep 10 develop runs already carried thesize-limit-actionartifact — so the action took the Sep 8 build and stopped.The warning banner didn't fire because
isLatestwas computed aslatestWorkflowRun.id === <baseline>.id, wherelatestWorkflowRun = filtered[0]came from the same stale listing. When the API omits recent runs,latestWorkflowRunis stale in the exact same way, soisLatestwas triviallytrue. The banner could only ever catch "a newer run exists but has no artifact yet" — never "newer runs are missing from the response entirely," which is the failure that actually occurred.Approach
Resolve the baseline from git history instead of the run index:
repos.listCommits({ sha: branch })— authoritative and strictly ordered newest-first — and pin each candidate run by exacthead_sha.head_shais a precise key with no ordering/event-index dependency, so recent commits can no longer be silently skipped.isLatestis now truthful:trueonly when the artifact is found on the tip commit, otherwisefalse(banner fires) with a log line stating how many commits behind the baseline is.event: 'push'filter is dropped — thesize-limit-actionartifact is only ever uploaded on the base-branch push path, so a PR run for the same SHA can't carry it, and dropping it avoids relying on the same lagging index.The return shape (
{ artifact, workflowRun, isLatest }) is unchanged, soindex.mjsneeds no changes.🤖 Generated with Claude Code