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.
Since we run clippy on Rust 1.42.0 we still get warnings about the
presence of clippy::match_bool lints. That lint has been moved from
'Style' to 'Pedantic' in Rust 1.45.0 and onwards however, so let's
silent it in our clippy runs too.
All bat tags begin with a small 'v', so no need for a generic pattern in
the CI script. This will also help us ensure we keep the same format on
future tags.
Not only when a release tag is pushed. Also publish these Debian
packages as artifacts. This makes PR workflows more similar to release
work flows, and reduces risk of build system regressions that we don't
detect until we make a new release.
For #1474
This enables us to later always build Debian packages. If you try to use
a git sha as Debian package version you will get an error:
dpkg-deb: error: parsing file '_staging/dpkg/DEBIAN/control' near line 2 package 'bat':
error in 'Version' field string 'd2963ce4': version number does not start with digit
so we need to use a version that is always available.
We duplicate the bat version in another place here which is a bit bad,
but it is already duplicated a lot, so we don't make things
significantly worse. It is still kind of nice to not have to figure out
a good and robust way to parse out the version from Cargo.toml in the CI
script.
For #1474
The end goal is to upload the same artifacts for a PR as we deploy
during a release, to make a regular PR pipeline as similar as possible
to a deploy.
The first step is to move 'Upload build artifacts' to after 'Package' so
we can upload the same files. Also change the name and artifacts to be
more similar to what we deploy for a release.
For #1474
This results in a nicer workflow file that is easier to follow.
Also remove the unneccesary doc row that repeats what is already in the
matrix and that is annoying to keep up to date.
For #1474
