ci: proptests extra automation

[federico-stacks]

Description

This PR introduces a new workflow, proptest-extra-tests, triggered on the PR approval event.

The purpose of this workflow is to run newly introduced proptest tests with an increased sample size (PROPTEST_CASES= 2500) as an additional validation step. This execution happens only after the PR introducing the tests has been approved and is ready to merge.

New tests are detected by comparing the output of cargo nextest list between the HEAD and BASE branches. Any proptest tests present in HEAD but not in BASE are executed with the extended configuration.

NOTE:
For simplicity of implementation and review, this PR only introduces the new workflow and its core logic.
To fully resolve #6804:

• A follow-up PR will add persistence support for proptest regression.
• Another follow-up PR will introduce proper naming conventions for proptest tests to improve filtering (see Additional Info below).

Applicable issues

• fixes CI: Run new property tests extra on PRs #6804

Additional info (benefits, drawbacks, caveats)

On Approval execution
Since this workflow is triggered for any PR approval, safeguards are in place to ensure the expensive job runs only when necessary. The workflow runs only if all of the following conditions are met:

• The required approval quorum is reached (currently set to 2. Not able to retrieve it from repo configuration because api requires admin read access, and then a PAT)
• The BASE branch match the configuration (currently develop, can be expanded if we need it)
• The HEAD branch introduces new proptest tests (detected via a lightweight git diff check based on the test tagging #[tag(t_prop)])

Execution Optimizations
To reduce runtime and resource usage, the following optimizations are applied once gating conditions pass:

• HEAD branch:
  • Attempts to reuse the testenv
  • Falls back to a fresh setup if cache restoration fails
• BASE branch
  • Attempts to reuse Cargo cache and target/ artifacts generated by the HEAD branch

How to Activate This Workflow

• Merge this PR into the default branch (master?!)
• Add the Run New Proptest Tests job as a required Status Check in branch protection rules (this ensures the job must pass before merging).

Checklist

• Test coverage for new or modified code paths
• For new Clarity features or consensus changes, add property tests (see docs/property-testing.md)
• Changelog is updated
• Required documentation changes (e.g., rpc/openapi.yaml for RPC endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo

[federico-stacks]

@wileyj about How to Activate This Workflow in the Additional info section, are you fine with that? Do you prefer a different naming?

[wileyj]

@wileyj about How to Activate This Workflow in the Additional info section, are you fine with that? Do you prefer a different naming?

no concerns at all - this is how it's done normally, and this PR is targeting develop. so the process there will be merge this to develop, then after next release it will be merged to master and we can add the required status check at that point.

[wileyj]

@federico-stacks there is something to consider with 063896f

do any approvals count here? you may want to double-check the approvals are from known teams/users. else, i think any approvals may count (think of a random users "approving" a PR without write access).

[federico-stacks]

do any approvals count here? you may want to double-check the approvals are from known teams/users. else, i think any approvals may count (think of a random users "approving" a PR without write access).

Yes, they do. It’s probably not a big issue in this case since the workflow only runs additional tests, but I’ve tightened the check following your suggestion (looking for write+ permissions).

crc: d969dc2

[simone-stacks]

lgtm!

[federico-stacks]

just changed the tagging approach from #[tag(prop)] to #[tag(t_prop)] to prevent any module name clashing.

[wileyj]

outside of failing test, i think my comments are resolved (but please check @federico-stacks ).

once tests are passed and comments resolved (likely no action), i'll approve

[federico-stacks]

outside of failing test, i think my comments are resolved (but please check @federico-stacks ).

once tests are passed and comments resolved (likely no action), i'll approve

The failing test was due to a job timeout. Re-run and it passed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.98%. Comparing base (962e7ab) to head (aaef103).
⚠️ Report is 93 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff              @@
##           develop    #6952       +/-   ##
============================================
+ Coverage    60.61%   84.98%   +24.36%     
============================================
  Files          412      412               
  Lines       219362   219518      +156     
  Branches       338      338               
============================================
+ Hits        132974   186565    +53591     
+ Misses       86388    32953    -53435     

see 303 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 962e7ab...aaef103. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.