aglinxinyuan opened a new pull request, #6730: URL: https://github.com/apache/texera/pull/6730
### What changes were proposed in this PR? Upload the **frontend** Codecov coverage from a follow-up `workflow_run` workflow instead of directly from the `pull_request` build, so the Codecov PR comment posts reliably on fork PRs. **Problem.** A PR from a fork never receives `secrets.CODECOV_TOKEN` — the build runs on the `pull_request` event and GitHub withholds secrets from fork runs (`required-checks.yml` correctly uses `pull_request`, not `pull_request_target`). The `codecov/codecov-action` step in `build.yml` therefore falls back to Codecov's **tokenless** path, which is rate-limited. Under a burst of fork-PR uploads Codecov still processes the report to `state: complete`, but silently drops the PR comment. On the frontend test-coverage campaign this tracks almost perfectly with how many PRs were opened at once: | Time (UTC) | opened together | got a Codecov comment | |---|---|---| | 07-16 10:35 | 6 | 5 / 6 | | 07-20 09:13 | 3 | 3 / 3 | | 07-20 21:32 | 3 | 1 / 3 | | 07-21 03:30 | 10 | 0 / 10 | **Fix.** Split the upload in two: ``` before (fork PR): build [pull_request, no token] ──tokenless──► Codecov ✗ comment dropped under burst after (fork PR): build [pull_request] ──artifact──► codecov-upload [workflow_run, token] ──► Codecov ✓ comment ``` - `build.yml` (frontend job) no longer calls `codecov-action`. It stages `lcov.info` + the two JUnit reports as the `codecov-frontend` artifact, together with the PR number / head sha / branch. (The `workflow_run` event resolves to the default branch and its `pull_requests` array is empty for forks; and the PR build checks out the merge commit while Codecov keys on the PR **head** sha — so these are stashed explicitly.) - New `codecov-upload.yml` fires on `workflow_run` after **Required Checks** completes. It runs in the base-repo context — where `CODECOV_TOKEN` *is* available — downloads the artifact, and re-uploads with the token. Authenticated uploads aren't subject to the tokenless rate limit, so the comment posts reliably even in bursts. This is Codecov's documented pattern for fork PRs. Scope is the **`frontend` flag only** — a proof of concept where the problem was observed. Every other flag still uploads directly from `build.yml`; converting them is a mechanical follow-up if we like this approach. ### Any related issues, documentation, discussions? Reported on #6685. ### How was this PR tested? - **This can't run on its own PR.** `workflow_run` workflows only trigger from the copy of the file on the **default branch**, so `codecov-upload.yml` has no effect until it lands on `main`. It also exposes a `workflow_dispatch` entry (`run_id` input) so the upload can be re-run against any finished *Required Checks* run to validate it right after merge. - YAML validated locally for both files. The staged paths (`frontend/coverage/gui/lcov.info`, `frontend/junit.xml`, `frontend/junit-browser.xml`) are exactly the ones the removed `codecov-action` steps consumed, confirmed against a recent frontend job log. `override_commit` / `override_branch` / `override_pr` are valid `codecov-action` v7 inputs. Reviewer call-outs: - Removing the direct frontend upload means that, once merged, frontend coverage depends entirely on `codecov-upload.yml`. If anything is off, revert is just these two files — recommend a `workflow_dispatch` smoke test against a recent run immediately after merge. - `workflow_run` runs with repo secrets while consuming an artifact built from (possibly fork) PR code. The token is never exposed to that artifact; only the metadata is used, and it is sanitized to its expected charset (numeric PR, hex sha) before reaching the Codecov CLI. This is the standard, accepted trade-off of the pattern. - Backport builds are intentionally excluded from staging (they check out a different ref and would collide on the artifact name across the target matrix). ### Was this PR authored or co-authored using generative AI tooling? Yes. Generated-by: Claude Code (Opus 4.8 [1M context]) -- 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]
