coverage ci 是否必要?

[foxzool]

耗时挺多

[foxzool]

This was generated by AI during triage.

Triage for #456: coverage ci 是否必要?

Summary: Reporter (maintainer) questions the value of the dedicated Coverage CI workflow, noting it takes significant time ("耗时挺多").

Verification of claim

• Recent runs of the Coverage workflow take ~15-17 minutes (e.g. 974s / 1015s on completed runs for PRs on main branch).
• Confirmed by inspecting .github/workflows/coverage.yml:
  • Runs on pull_request: branches: [main] and push: branches: [main].
  • CARGO_INCREMENTAL=0 + rust-cache explicitly disabled (incompatible with coverage collection).
  • Executes instrumented tests: cargo llvm-cov --workspace --all-features --lib --tests.
  • Then collects summary, per-crate reports, LCOV, missing lines, HTML artifact.
• Duplication: The main ci.yml test job already runs cargo test --workspace --all-features on the same events. Coverage re-executes tests under instrumentation.

Relevant codebase facts

• This coverage = Rust source line coverage via cargo-llvm-cov. Global gate 40% enforced only on main push (PRs are informational only + artifact). Per-crate soft baselines defined in workflow.
• Typed API coverage (separate, arguably more relevant for this SDK): just api-coverage, tools/validate_apis.py, tools/api_coverage.toml, docs/typed-api-coverage.md, release gate logic in typed-coverage-release-criteria.md + tools/typed_coverage_release.toml. Focuses on implemented vs. official Feishu API surface.
• Local usage: just coverage, just coverage-check, just check-all (includes coverage).
• References in TESTING.md, developer checklists, and quality infrastructure history (see e.g. past work on CI quality gates).
• No .out-of-scope/ directory exists in the repo.

Checks (per triage process)

• Redundancy: Searched for existing "disable coverage CI", "coverage optional", or equivalent. The coverage workflow and just targets exist and are the implementation. No prior removal logic. Past related issues were about adding coverage reporting or typed API coverage dashboards (none matched "is line coverage CI necessary?").
• Prior rejection: .out-of-scope/ does not exist; no files to match against.
• No previous triage notes or comments on coverage ci 是否必要? #456.

Recommendation

Category: enhancement
Labels to apply: type:ci (CI、自动化与 workflow 调整) + scope:quality (测试、错误处理、CI 与质量门禁)

State: ready-for-human

Rationale:
This is fundamentally a judgment / policy call:

• Trade-off between CI time budget and the signal provided by line coverage reports + 40% gate.
• For an SDK wrapping 1500+ external APIs, "typed API coverage" + contract validation + feature matrix testing are stronger quality indicators than raw line %.
• The 40% threshold is modest.
• Requires deciding on CI design (trigger scope, duplication, artifact value) and updating docs/processes. Not a mechanical code task.

It is not yet "agent ready" without a chosen direction (e.g. "remove the PR trigger and update docs").

Proposed options (human to pick / refine)

1. Scope down triggers — Change coverage.yml to run only on push to main (drop PRs). Saves time during active review; gate + reports still happen post-merge.
2. Remove coverage CI — Delete (or comment out) the workflow. Treat line coverage as a local tool (just check-all). Update TESTING.md, checklists, and check-all references. Double down on typed coverage for CI.
3. Keep and enhance visibility — Add coverage % delta or link to artifact in a PR comment step. Investigate whether limited caching or crate subset is viable.
4. Other — Adjust MIN_COVERAGE, run only on release branch / schedule, or merge some reporting into existing jobs.

Next step: Maintainer direction on preferred option (or alternative). Once decided, can be turned into a concrete task (ready-for-agent or direct human PR).

[foxzool]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Scope the Coverage CI workflow to trigger only on pushes to main (remove the pull_request trigger), eliminating duplicated ~16-minute instrumented coverage runs on PRs targeting main while preserving the gate and reports on main.

Current behavior:
The Coverage workflow triggers on both pull_request (branches: [main]) and push (branches: [main]). It runs a full cargo llvm-cov --workspace --all-features (no incremental compilation, rust-cache disabled) plus report generation, HTML artifacts, per-crate summaries, LCOV, and missing-lines output. This duplicates test execution from the primary test job in ci.yml.

On PRs the coverage result is informational only. The MIN_COVERAGE (40%) gate only runs on push to main. Contributors pay the time cost (~15-17 min observed) during active PR review.

Local commands (just coverage, just coverage-check, just check-all) and typed API coverage remain separate concerns.

Desired behavior:

• The Coverage workflow runs exclusively on push to main (including merges that land on main).
• No Coverage job is started for pull requests targeting main.
• All existing report generation, artifact upload, per-crate analysis, and the coverage threshold enforcement continue to execute when the job does run on main.
• Local coverage tooling and commands are unaffected.
• Documentation is updated to reflect that CI coverage reports are produced on main (post-merge) and that developers should use local just coverage during PR development.

Key interfaces:

• GitHub Actions on: trigger configuration for the Coverage workflow — specifically the presence/absence of the pull_request block limited to main.
• The overall job behavior (report steps, threshold check logic, artifact upload) must remain identical when triggered.
• References in documentation that describe when Coverage CI executes (e.g. links titled "Coverage CI").

Acceptance criteria:

• Updating or creating a PR targeting main does not cause the Coverage workflow to appear in the PR's Checks / Actions runs.
• A direct push to main (or a merge) triggers the Coverage workflow and completes the full job, including the global coverage gate on main.
• just coverage, just coverage-check, and just check-all continue to function exactly as before (no changes to justfile targets required).
• Relevant documentation (at minimum TESTING.md) is updated to accurately describe the new CI trigger rules for coverage reports.
• The workflow file remains syntactically valid and the job definition is unchanged except for the on: triggers.
• No other workflows or scripts are modified.

Out of scope:

• Deleting or disabling the entire Coverage workflow / line coverage mechanism.
• Changing MIN_COVERAGE, per-crate thresholds, or any report generation logic.
• Touching typed API coverage (just api-coverage, tools/validate_apis.py, api_coverage.toml, etc.).
• Adding caching, splitting crates, or other performance workarounds inside the llvm-cov invocation.
• Modifying the primary CI test job, feature-combinations matrix, or any workflow other than Coverage.
• Altering local development commands or developer checklists beyond accurate documentation of CI behavior.