aglinxinyuan commented on PR #6730: URL: https://github.com/apache/texera/pull/6730#issuecomment-5042911733
Good questions. **Why only frontend?** It isn't frontend-specific — the tokenless-under-burst drop can hit any flag on a fork PR. Frontend is just where it surfaced: (1) the coverage campaign has been opening batches of ~10 frontend-only fork PRs within a couple of minutes, and (2) each frontend PR fires *three* tokenless uploads (coverage `lcov.info` + unit `junit.xml` + browser `junit-browser.xml`) vs one–two for the other flags — so a frontend burst runs up ~30 tokenless uploads in ~2 min and trips Codecov's tokenless rate limit fastest. amber/pyamber/agent-service/platform fork PRs would behave the same in comparable bursts. **Defer all flags to one job?** I think that's the right direction, and I scoped the PoC to frontend mostly to keep the diff reviewable — but it's not a pure copy-paste; a few flags need real care: - **amber** is the tricky one. Its coverage is a glob across ~8 modules (`./**/target/.../jacoco.xml`), every file sharing the same basename. The frontend PoC copies named single files into a flat dir, which for amber would clobber all but one module and silently drop 7/8 of its coverage. That flag needs the directory tree preserved (or per-module artifact paths) + reworked globs on the download side. - **amber-integration** is results-only (no coverage) and uploads from *both* the ubuntu and macOS legs — so it can't reuse frontend's `ubuntu-only` guard (that would drop macOS) and needs per-leg artifact names to avoid an `upload-artifact` name collision. - Every flag's staging also has to carry the `backport_target_branch == ''` guard (the backport matrix runs the same jobs, so `codecov-<flag>` would otherwise collide within one run) and stash the PR/sha/branch overrides, or the deferred upload misattributes coverage to the default-branch tip. So: worth doing, but I'd treat it as a deliberate second pass rather than a switch-flip. One honest reliability caveat: routing everything through the deferred workflow makes it the *sole* upload path, and since `Codecov Upload` runs on `workflow_run` it isn't a required PR check — if it fails, coverage just silently goes missing until someone re-runs it manually. Worth weighing before we move every flag over. Happy to put up that follow-up if you want to go this route. **Does batching reduce the allowance?** Not really. There's no per-upload quota we're bumping into on the coverage side — the pressure is specifically the *tokenless* rate limit. Each module already reports under its own flag against its own file, so they can't be collapsed into fewer uploads without cross-tagging every module onto every flag, and the artifact hand-off (upload + download) actually adds a bit of Actions work vs an inline upload. What fixes it is *authentication*: the deferred job runs in base-repo context where the token is available, and token uploads aren't subject to the tokenless limit. So the win is reliability, not fewer uploads. -- 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]
