ci: release from actions, only test changed files #374
Conversation
This commit introduces release automation triggered by button clicks in Github Actions, guarded by a check on whether all the Cargo.toml files contain the same version string. On PRs, changes to documentation no longer trigger code tests. Similarly, changes to code that don't update documentation do not trigger documentation tests. Changes that fail at the `cargo check` stage abort early to prevent lengthy CI builds of the installer and firmware. Commits on the `main` branch always run the full test suite regardless of what changed. Releases also run the full check, test, build and publish suite.
| steps: | ||
| - uses: actions/checkout@v4 | ||
| - name: Check formatting | ||
| run: cargo fmt --all --check |
There was a problem hiding this comment.
This is a functionality change: now we enforce that the code has been run through cargo fmt.
If we accept this we can drop one of the "have you run a linter" PR checklists. I can do that in this PR if we like this.
| - name: Ensure all Cargo.toml files have the same version defined. | ||
| run: | | ||
| defined_versions=$(find lib bin installer rootshell telcom-parser -name Cargo.toml -exec grep ^version {} \; | uniq | wc -l) | ||
| find lib bin installer rootshell telcom-parser -name Cargo.toml -exec grep ^version {} \; |
There was a problem hiding this comment.
This is here to help with debugging actions when this guard fails, the versions will be printed to the actions log.
| # https://github.com/EFForg/rayhunter/actions/workflows/release.yml | ||
| name: Release rayhunter | ||
| on: | ||
| workflow_dispatch: |
There was a problem hiding this comment.
We could also trigger this on a v* tag push. My feeling is that starting with one canonical release mechanism is the right way though.
There was a problem hiding this comment.
Yeah I think having one release mechanism and documentation on how to trigger a release.
|
The addition of all the |
oopsbagel
requested review from
cooperq,
wgreenberg,
untitaker,
alliraine and
gaykitty
|
For future work, I'd like to:
Each of those should be pretty easy to implement individually. |
|
Replying to myself:
I will probably do this in a separate PR later, I think it will make the workflows easier to read. If anyone wants to PR against my branch they can. |
This branch introduces release automation triggered by button clicks in Github Actions, guarded by a check on whether all the Cargo.toml files contain the same version string.
On PRs, changes to documentation no longer trigger code tests. Similarly, changes to code that don't update documentation do not trigger documentation tests. Changes that fail at the
cargo checkstage abort early to prevent lengthy CI builds of the installer and firmware.Commits on the
mainbranch always run the full test suite regardless of what changed.Releases also run the full check, test, build and publish suite.
Pull Request Checklist
cargo fmtNotes
We can iterate on naming, functionality, etc. It's possible to break up the main file into smaller components (e.g., build.yml, mdbook.yml, etc, all triggered by main.yml conditionally). I've tested this a lot in my own repo, but it's always possible I've overlooked something.
Fixes #370