Add composite actions for shared Rust CI checks and build context - #1
Conversation
|
After thinking about it and seeing the application of it, can we change the inputs to have our defaults so we can override them if necessary, but just leave them empty in our 99% case? |
|
Agreed, I think there are very rare cases were we don't want cargo fmt to run, to true is the correct default here IMO. Additionally, I think some comments on how the matrix build works / what some of the args of fmt / clippy / ... mean would support readability of our CI code for first time contributors. |
- Enable formatting and Clippy checks by default.
- Use common Clippy arguments ("--all-targets --locked") in the shared check step.
- Document formatting, Clippy and build context behavior.
|
One more point for the general discussion: The current action consumers pull this action via the main branch. This means any commit on main changes behaviour for consumers, i.e. rolling release without consumer interaction. Do we want that, or do we want to add tagged releases here / pin the intended commit via hash? |
- Change description of the rust-build-context composite action.
As all of them live in the same organization, I would be fine with keeping |
Fine with me :) |
3 participants
This PR addresses csaf-rs/csaf#787.
Note: This PR is followed by 4 other corresponding PRs in the consuming repositories and should be merged before those, since they depend on the composite actions introduced here.
This PR adds two shared composite actions for Rust CI:
rust-checksfor formatting and Clippy checksrust-build-contextfor the Rust versions, Git version label, target reference, and build target matrix currently calculated in thecsafworkflow (build.yml)The goal was to reduce duplicated GitHub Actions code while keeping repository-specific CI checks and other workflow logic in the individual repositories.
I tested both actions as far as possible with dedicated local test workflows before integrating them into the consuming repositories, since some behavior can only be fully checked in the actual upstream workflows.
For
rust-build-context, I ran the original implementation fromcsaf/build.ymland the composite action in the same job and compared all outputs directly:msrv-version,stable-version,git-version,targetref,targets.The comparison passed for
workflow_dispatch, pull requests, and tag pushes. I also validated the generated target matrix (build.yml) as JSON and checked how the composite actions outputs can be forwarded as job outputs and called from a dependent job.For
rust-checks, I tested the action on the same runner combinations used by the CSAF build.yml.The test covered the shared format check, parsing of custom Clippy arguments and the shared Clippy check with target-specific arguments (used by CSAF build.yml).