175

[RAprogramm]

Summary

Implemented Phase 1 enterprise-grade CI/CD improvements with concurrency control, code coverage reporting, and matrix strategy for multi-version testing.

Changes

#176 Concurrency Control

• Added concurrency groups to ci.yml and release.yml
• Automatically cancels in-progress runs when new commits pushed to PRs
• Prevents redundant CI resource usage

#177 Code Coverage Reporting

• Integrated cargo-llvm-cov for accurate coverage tracking
• Added dedicated coverage job with Codecov integration
• Generates LCOV reports for detailed coverage analysis
• Foundation for coverage badges and PR checks

#178 Matrix Strategy

• Introduced matrix testing across MSRV (1.90) and stable Rust
• Separated MSRV detection into reusable job output
• Optimized job execution: tests run on both versions, but fmt/deny/audit run once
• README operations constrained to MSRV to avoid conflicts

Benefits

• Faster Feedback: Parallel execution of tests across Rust versions
• Resource Efficiency: Cancelled redundant runs save CI minutes
• Better Coverage: Visibility into test coverage trends
• Version Compatibility: Automatic verification against MSRV and stable

Test Plan

• Workflows validate successfully (YAML syntax)
• Local tests pass (cargo test --all-features)
• Cargo fmt and clippy pass
• No regression in existing functionality

Next Steps (Phase 2 & 3)

• Performance benchmark tracking in CI
• Job parallelization optimization
• Multi-platform testing (macOS, Windows)
• SBOM generation and artifact signing

Closes #176
Closes #177
Closes #178

• General fix: Explicitly set a permissions: block so that the workflow (or individual jobs) only receive the minimal required set of permissions for their steps to work.
• Best single fix for this snippet:
  Add a top-level permissions: block (applies to all jobs) with the most restrictive feasible permissions, e.g. permissions: { contents: read }, and extend specific jobs that need more (here likely the ci job, specifically where it commits, pushes, or makes a pull request) with a permissions: block giving contents: write and pull-requests: write.
• Specific changes:
  • Add at the top level of the workflow (permissions: after name: and before on:) with contents: read.
  • In the ci job, add a permissions: block setting:

    permissions:
      contents: write
      pull-requests: write

    before runs-on: ubuntu-latest.
• What is needed:
  • Insert top-level permissions: contents: read
  • Add job-level explicit permissions for ci job as above.

---

To resolve this issue, add a permissions: block specifying the minimum required permissions, thereby adhering to the principle of least privilege. The best practice is to place this block at the top level of the workflow YAML file, so that all jobs inherit least-privilege permissions unless overridden at the job level.

• Add a top-level permissions: block after the name: declaration, before on:.
• For most CI/CD workflows that do not require write access to repository contents, the recommended setting is contents: read.
• If jobs require other permissions (e.g., pull-requests: write or contents: write for auto-committing changes), consider setting those at the individual job level. However, as a minimal fix and starting point, set contents: read at the top level.

What to change:

• Add after line 5: name: Reusable CI a block:

  permissions:
    contents: read
  

• If later, any job (e.g., the "auto-commit README changes" step) is shown to need contents: write, you may override the permissions for that specific job. For now, the minimal recommended fix is to set the top-level block to restrict all jobs to read-only.

---