feat: add cargo hack check to ci

[Jiloc]

Description

Supersedes #6262

This PR introduces a new workflow (cargo-hack-check.yml) to verify that all feature flag in our workspace compile successfully.

The goal is not to accidentally break our support for wasm in future PRs, and prevent accedentally break feature flags like it recently happened in #6228

It is structured into three stages:

• setup: A quick preliminary job that reads the Rust toolchain version from the rust-toolchain file. This value is passed to subsequent jobs to ensure they all use the correct and consistent Rust version.
• Parallel Checks: Two jobs run in parallel:
  • native-targets: This job handles builds for linux and windows (x86_64-unknown-linux-gnu and x86_64-pc-windows-gnu). It runs cargo hack check across all crates and for each feature individually. It would be possible to also do it for all permutations, but it would take too long for a CI work, I suppose.
  • wasm-targets: This job specifically handles our WASM builds. It uses a matrix strategy to run two separate checks for our distinct WASM use cases:
    • One for the wasm-web feature set.
    • One for the wasm-deterministic feature set.
      This job has fail-fast: false so that a failure in one WASM check doesn't prevent the other from running.

Also: .github/workflows/core-build-tests.yml was renamed to ‎.github/workflows/constants-check.yml. This workflow contained a subset of the cargo checks that we are now performing via cargo hack. After removing those check, I decided to rename it.

When running cargo hack check, it detected 2 failing cases, fixed in this PR:

• stacks-node: the Cargo.toml had two features that referenced stacks-signer, which is not a dependency but a dev-dependency.

  • monitoring_prom: not needed
  • testing: already present in the declaration of stacks-signer under the dev-dependencies

• clarity: fixes cargo check --no-default-features --features testing. The change was needed because the testing feature is relying on symbols behind the rusqlite feature.

Applicable issues

• fixes #

Additional info (benefits, drawbacks, caveats)

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[fdefelici]

LGMT!

Just one note: at the time of writing, the Check the constants from stacks-inspec job (from constants-check.yml) still appears as pending, even though the workflow summary graph shows it as green (completed and passed).

Could just be a transient github issue?!

PR CHECKS

PR WORKFLOW SUMMARY
https://github.com/stacks-network/stacks-core/actions/runs/16675997792?pr=6328

[Jiloc]

LGMT!

Just one note: at the time of writing, the Check the constants from stacks-inspec job (from constants-check.yml) still appears as pending, even though the workflow summary graph shows it as green (completed and passed).

Could just be a transient github issue?!

Thanks for pointing it out! It's kinda strange. I run the workflow again, and the job seems to succeed without problems https://github.com/stacks-network/stacks-core/actions/runs/16675997792/job/47202664222 . But I am not sure why it still looks like is pending in here. @wileyj do you have any insights?

[wileyj]

LGMT!
Just one note: at the time of writing, the Check the constants from stacks-inspec job (from constants-check.yml) still appears as pending, even though the workflow summary graph shows it as green (completed and passed).
Could just be a transient github issue?!

Thanks for pointing it out! It's kinda strange. I run the workflow again, and the job seems to succeed without problems https://github.com/stacks-network/stacks-core/actions/runs/16675997792/job/47202664222 . But I am not sure why it still looks like is pending in here. @wileyj do you have any insights?

that check was definitely run (successfully). best guess is it's a UI issue or the status wasn't reported after it completed. a retry may trigger it

update:
triggered

[Jiloc]

closing and reopening - test if the pending check will be solved

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.00%. Comparing base (3ece8b5) to head (ed151c6).
⚠️ Report is 32 commits behind head on develop.

❌ Your project status has failed because the head coverage (67.00%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #6328      +/-   ##
===========================================
+ Coverage    65.36%   67.00%   +1.63%     
===========================================
  Files          552      552              
  Lines       351502   351502              
===========================================
+ Hits        229768   235526    +5758     
+ Misses      121734   115976    -5758     

see 394 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 3ece8b5...ed151c6. 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.

[wileyj]

LGMT!

Just one note: at the time of writing, the Check the constants from stacks-inspec job (from constants-check.yml) still appears as pending, even though the workflow summary graph shows it as green (completed and passed).

Could just be a transient github issue?!

PR CHECKS

PR WORKFLOW SUMMARY https://github.com/stacks-network/stacks-core/actions/runs/16675997792?pr=6328

found the reason - the name of the workflow was changed (in this PR), so the required status check will not be run until that is modified.
when this PR is ready to merge, we'll have to adjust the required checks, and note that once it is changed - any downstream PR may run into a similar issue until they rebase.

[wileyj]

lgtm

[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.