* 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.
From the discussion in #1734, instead of using `env.PROJECT_NAME`,
`steps.strip.outputs.BIN_NAME` could potentially be a better choice as
the filename needs to match the called executable for bash-completion's
on demand loading to work. This `BIN_NAME` needs to stay in sync with
`env.PROJECT_EXECUTABLE` which is replaced in the template, but not
available for the deb build at this stage.
Follow the same route as for the fish/zsh completions for now for the
sake of consistency.
Closes#1733
