* ensure `cargo clippy` treats all suggestions as errors in CI
* ensure `cargo clippy` runs with the latest stable Rust because Clippy is MSRV-aware, so it will not suggest anything unapplicable. Also note that whenever new release comes out, Clippy might temporarily show new errors - I think this is better than forgetting to update the version somewhere, and keep running older tools.
* Update actions/checkout to the latest v5
Our CI runs a fair amount of unaudited third party code. I'd like to
stop using my Personal Access Token until we have had time to security
harden our CI.
* Mention changelog requirements in CONTRIBUTING
* Refer to CONTRIBUTING in changelog workflow
* Clarify when changelog entries are necessary
---------
Co-authored-by: Martin Nordholts <martin.nordholts@codetale.se>
* Added changelog item check
Fetch the base branch and diff correctly
- See: https://github.com/actions/checkout/issues/160
Improve organisation
Add some echo for easier debugging
Fix bad variable syntax
Clarify the double-print in the success case
* Write to changelog
* Don't block dependabot PRs
This opens up future possibilities:
* GitHub's auto-merge feature that merges a PR once CI passes
* Auto-merge of dependabot PRs that pass CI
But before we do any of that we need to have this new job active for a
while to see that it works.
This CI check will fail if there are crates with known security vulnerabilities in Cargo.lock.
It will not fail because of warnings. We currently have two warnings.
Note that cargo-audit is installed by default on GitHub's Ubuntu
runners.
From now on, any changes to the help texts will be visible in PR diffs,
which will make it very easy to review, and very hard to accidentally
miss changes to help texts.
If a contributor makes a change to help texts, the `cargo test` failure
text they will see contains instructions on how to update the blessed
help texts:
error: expect test failed
--> ../doc/long-help.txt
You can update all `expect!` tests by running:
env UPDATE_EXPECT=1 cargo test
In short, to update blessed help texts, one simply does
env UPDATE_EXPECT=1 cargo test
Do not run the tests if the `git` feature is missing, since then
`--diff` will be missing from `--help`. And do not run the tests on
Windows, because then the help text will contain the term `.exe`.
Move man page step to after cargo doc step so that the man page exists
when we look for it.
* Simplify release-checklist.md by printing `-h`, `--help` and `man` in CI
Note that we run `find . -name bat.1` before we run anything with
`--all-features`, because `--all-features` is considered a separate
target, and so we will get a different (but identical) `bat.1`. For
example, we might have these:
./target/debug/build/bat-218e9538b4996215/out/assets/manual/bat.1
./target/debug/build/bat-89d6f56802af023f/out/assets/manual/bat.1
By showing the man page earlier, there is only one `bat.1` to pick from.
* Use plain `man $(find . -name bat.1)`
There is now a new stage in the CICD workflow present, which will build
`bat` with the `BAT_SYSTEM_CONFIG_PREFIX` set to load the config file
from `/tests/examples/system_config/bat/config`, plus a basic set of
tests, to ensure the feature is working as expected. By default the
tests are set to ignored, as they need special setup before they can be
run.
Mainly to make it easier to see what went wrong when it fails.
If this ever gets of out sync with a particular Rust version, we can most likely
save the situation by introducing a `rustfmt.toml` file.
