test(frontend): cover combineValidation#6685
Conversation
Automated Reviewer SuggestionsBased on the
|
|
how come the coverage report is not generated on those frontend test only PRs? cc @aglinxinyuan can you help investigate it? |
There was a problem hiding this comment.
Pull request overview
Adds focused frontend unit test coverage for ValidationWorkflowService.combineValidation (a static reducer used by workflow/operator validation), ensuring expected behavior for validity aggregation and invalid-message merging.
Changes:
- Added unit tests for
combineValidationcovering empty input, all-valid inputs, valid+invalid filtering, multi-invalid merging, and duplicate-key override behavior. - Updated imports in the existing spec to reference
Validation/ValidationErrortypes used by the new tests.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Dug into this. The coverage is uploaded and fully processed on these PRs — the only thing missing is the last step, Codecov posting the PR comment. It's the tokenless upload path on fork PRs, not our These PRs are from forks, so GitHub doesn't hand secrets to the It tracks almost perfectly with how many PRs were opened at once:
#6685 was in that 10-PR burst. #6687 was too and stayed silent for a day — until it picked up a Ruled out: not "no coverage change" ( Two fixes:
|
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…pache#6730) ### What changes were proposed in this PR? Route **every** Codecov flag's upload through a follow-up `workflow_run` workflow instead of uploading inline from the `pull_request` build, so fork PRs get authenticated (non-rate-limited) uploads and a reliable Codecov PR comment. **Problem.** A PR from a fork never receives `secrets.CODECOV_TOKEN` (the build runs on `pull_request`, and GitHub withholds secrets from fork runs). The inline `codecov-action` steps therefore fall back to Codecov's *tokenless* path, which is rate-limited; under a burst of fork-PR uploads Codecov still processes the report but silently drops the PR comment (reported on apache#6685). **Fix.** - `build.yml`: each coverage job stages its reports as a `codecov-<flag>` artifact via `.github/scripts/stage-codecov.sh` (`coverage/` + `results/` + pr/sha/branch identifiers) instead of uploading inline. The script preserves the directory tree so amber's ~8 same-basename module `jacoco.xml` don't collide. Staging is skipped on backport builds (artifact-name collisions across the target matrix) and pinned to the single producing leg for the dual-OS / multi-python jobs. - `codecov-upload.yml`: a per-flag matrix runs on `workflow_run` after **Required Checks**, in the base-repo context where `CODECOV_TOKEN` is available. It downloads each artifact and re-uploads with the token, using `directory:` scoping so Codecov's search finds every file per flag. - **Failure surfacing:** coverage uploads fail hard, and a `notify-failure` job then comments on the PR (a link to the failed run + the `run_id` to manually dispatch) — Codecov only self-comments on success, so this covers the failure case. A delayed / no-runner run posts nothing at all, which is itself the signal that the upload is stuck. Flags covered: frontend, amber, amber-integration (test-results only), pyamber, agent-service, and the 6 platform services. Why not batch into fewer calls: Codecov requires one upload per flag (flags in a single upload apply to *all* its files, and carryforward — which `codecov.yml` relies on — needs the flag set at upload time), with no path-based auto-assignment, so the calls can't be collapsed without dropping the per-flag / carryforward model. The token — not batching — is what removes the tokenless rate-limit pressure. ### Any related issues, documentation, discussions? Reported on apache#6685. ### How was this PR tested? - `workflow_run` only triggers from the copy of the file on the default branch, so `codecov-upload.yml` activates only after merge; it exposes a `workflow_dispatch` (`run_id`) entry to validate against a finished *Required Checks* run immediately after merge. - `.github/scripts/stage-codecov.sh` was exercised locally: multi-module glob → no basename collisions, single-file flags, and the empty-PR (push) case. - YAML validated for both workflows. The staging half runs in **this PR's own CI**, so the `codecov-<flag>` artifacts can be inspected on this run. - Reviewed for coverage parity (every prior inline upload is still staged + re-uploaded — nothing dropped), artifact-name collisions (backport guard + per-leg pinning), and deferred-upload correctness (empty-override omission, missing-artifact handling, `matrix.coverage` gating). - First-live-run check after merge: confirm each flag's test-results (Test Analytics) JUnit files are discovered under `directory:` — best-effort, and separate from the coverage report. Since the deferred workflow can only activate on `main`, if anything is off the whole change reverts as a single PR. ### Was this PR authored or co-authored using generative AI tooling? Yes. Generated-by: Claude Code (Opus 4.8 [1M context])
|
Merged main to trigger coverage report. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6685 +/- ##
============================================
- Coverage 76.27% 75.38% -0.90%
+ Complexity 3452 3446 -6
============================================
Files 1161 1161
Lines 45917 45916 -1
Branches 5100 5100
============================================
- Hits 35025 34615 -410
- Misses 9327 9678 +351
- Partials 1565 1623 +58
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Closing as it doesn't increase coverage: #6685 (comment) |
|
Will reevaluate after fixing the Codecov Report. |
…he#6824) ### What changes were proposed in this PR? Follow-up to apache#6730. The deferred `Codecov Upload` workflow hardcoded all 11 flags in its matrix and tried to download each from the source run. On a label-gated PR — e.g. a frontend-only PR that only stages `codecov-frontend` — the other 10 legs hit `##[error] Artifact not found for name: codecov-<flag>`, which looks like a name mismatch; and because the download used `continue-on-error: true`, a genuinely failed download was swallowed, the leg went green, and `notify-failure` never fired. **Fix:** add a `discover` job that lists the source run's *actual* `codecov-*` artifacts and drives the upload matrix from that (`fromJSON`), and drop `continue-on-error` on the download. - **No more spurious errors** — only the flags the source run actually built are processed; a frontend-only PR runs one clean leg. - **Failures surface** — a listed artifact that then fails to download or upload fails the leg, so `notify-failure` fires (previously it went silently green). - Also removes the hardcoded flag list, so adding a `platform` service no longer needs a matching matrix row here. Observed on the first live run after apache#6730 merged ([run 29984668372](https://github.com/apache/texera/actions/runs/29984668372), triggered by a frontend-only PR's checks): `frontend` uploaded fine, but 10 legs logged `Artifact not found` for the label-gated flags and the run still went green. ### Any related issues, documentation, discussions? Follow-up to apache#6730 (reported on apache#6685). ### How was this PR tested? - `workflow_run` only activates from the copy of the file on the default branch, so this can't run on its own PR. Validated by YAML lint and an adversarial review of the discover → upload → notify flow: empty-flags cleanly skips (no failure, no notify), the dynamic `fromJSON` matrix handles one or many flags, a download/upload failure now fails the leg and fires `notify-failure`, `amber-integration` (results-only) skips the coverage step via `hashFiles`, and the `workflow_dispatch` path resolves the run id. - The `workflow_dispatch` (`run_id`) entry remains for manual post-merge validation against a finished *Required Checks* run. ### Was this PR authored or co-authored using generative AI tooling? Yes. Generated-by: Claude Code (Opus 4.8 [1M context])
What changes were proposed in this PR?
Any related issues, documentation, discussions?
Closes: #6684
How was this PR tested?
cd frontend && node --max-old-space-size=8192 ./node_modules/nx/dist/bin/nx.js test gui --watch=false --include=src/app/workspace/service/validation/validation-workflow.service.spec.ts, expect the suite passing.Was this PR authored or co-authored using generative AI tooling?
Co-authored with Claude Opus 4.8 in compliance with ASF