* 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
We can't use #[from] on Error::Msg(String) because String does not implement Error.
(Which it shouldn't; see e.g. https://internals.rust-lang.org/t/impl-error-for-string/8881.)
So we implement From manually for Error::Msg, since our current code was written
in that way for error-chain.
Use it like this:
cargo build --no-default-features --features quick-build-application
It reduces dependencies to build from 154 to 125, allowing quicker iteration
when developing the app.
Without this change, creating a PR triggers all jobs to run twice. Once
due to a push event and once due to a pull_request event.
Change to only trigger jobs due to push when pushing a tag or to the
master branch, to avoid duplicate jobs for each PR.
