tushardev-365 opened a new pull request, #43251:
URL: https://github.com/apache/superset/pull/43251
### SUMMARY
The nightly bundle-size baseline job has failed on every run since #42511
landed on 2026-08-15, so the baseline it exists to write has never actually
been written. The PR-time `bundle-size` job in `superset-frontend.yml` compares
against that baseline, so it has had nothing to compare against.
All three runs fail the same way, at the last meaningful step:
```
##[error]No commit information is found in payload: {
"schedule": "0 6 * * *",
...
```
The steps before it all pass, which is what makes this worth fixing rather
than reverting. Run 32001071380:
| # | step | result |
|---|---|---|
| 3 | Build Docker Image | success |
| 6 | Build production bundle with stats and analyzer report | success |
| 7 | Summarize bundle size | success |
| 8 | **Update bundle size baseline** | **failure** |
| 9 | Save bundle size history | skipped |
So each night the workflow does the full Docker build and the full
production bundle build, then throws the result away at the final step.
**Cause.** `benchmark-action`'s `getCommit` resolves the commit in three
stages:
```ts
async function getCommit(githubToken?: string, ref?: string):
Promise<Commit> {
if (github.context.payload.head_commit) { return
github.context.payload.head_commit; }
const pr = github.context.payload.pull_request;
if (pr) { return getCommitFromPullRequestPayload(pr); }
if (!githubToken) {
throw new Error(`No commit information is found in payload: ...`);
}
return getCommitFromGitHubAPIRequest(githubToken, ref);
}
```
A `schedule` payload has neither `head_commit` nor `pull_request` (the dump
in the log starts with `"schedule": "0 6 * * *"`), so without a token there is
no third stage and it throws.
This is also why the sibling job is fine and this one is not.
`superset-frontend.yml` passes `github-token` for `comment-on-alert`, but it
runs on `pull_request`, where the commit comes from `payload.pull_request` and
no API call happens. The nightly job is the one that actually *needs* the token
to resolve a commit, and it is the one that was missing it.
**Fix.** Pass `github-token`, matching the sibling job.
`getCommitFromGitHubAPIRequest` calls `repos.getCommit`, which the existing
top-level `permissions: contents: read` already covers, so no permissions
change is needed.
I checked that no other workflow uses this action, so this is the only other
place affected.
### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Not applicable, CI only.
### TESTING INSTRUCTIONS
This is a `schedule` / `workflow_dispatch` workflow, so it cannot run from a
fork PR and I could not execute it end to end. I would rather say that plainly
than imply coverage I do not have.
What I did verify:
- The failing step and the exact error come from run 32001071380 on master,
and the two runs before it fail identically.
- The three-stage `getCommit` logic above is from `src/extract.ts` in
`benchmark-action/github-action-benchmark`, and the pinned `52576c92` is
release v1.22.1.
- The file still parses under `yaml.safe_load`.
To confirm after merge, run `Frontend bundle size (nightly baseline +
analyzer)` via `workflow_dispatch`. Expected: step 8 records a data point
instead of throwing, step 9 saves the history cache, and the job summary shows
the bundle-size table. The next PR touching frontend code should then get a
real comparison rather than an empty baseline.
One thing I deliberately left alone: the build logs a `failed to configure
registry cache importer: apache/superset-cache:3.11-slim-trixie: not found`. It
is non-fatal, `superset-frontend.yml` uses the same `--cache-from` ref, and
`docker.yml` already has comments acknowledging that image can be unavailable,
so it reads as known and separate from this bug.
### ADDITIONAL INFORMATION
- [ ] Has associated issue:
- [ ] Required feature flags:
- [ ] Changes UI
- [ ] Includes DB Migration (follow approval process in
[SIP-59](https://github.com/apache/superset/issues/13351))
- [ ] Migration is atomic, supports rollback & is backwards-compatible
- [ ] Confirm DB migration upgrade and downgrade tested
- [ ] Runtime estimates and downtime expectations provided
- [ ] Introduces new feature or API
- [ ] Removes existing feature or API
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
