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
There is no usage of `steps.vars.outputs.REF_*` so no need to setup such
things. Also remove setting up REF_NAME and REF_BRANCH env vars, since
they are never read.
because we always use "stable". If we need to go back to using
matrix.job.toolchain, we should do it like in jobs.coverage, instead of
messing about with vars and outputs.
Turns out GitHub is clever enough to pick up clippy warnings from us
just running it, and showing them in PRs under a "Unchanged files with
check annotations (beta)" header.
The only warnings currently shown are style warnings, and we agreed we
don't want to risk putting off contributors over style issues. So
explicitly allow (don't warn in the logs for) this category of clippy
lints.
This means that the only clippy categories left that prints warnings
(Warn) are:
clippy::complexity
clippy::perf
And the only category of lints that fails the CI build (Deny) remains to
be:
clippy::correctness
See https://rust-lang.github.io/rust-clippy/master/index.html for a
catalog of all lints.
Only the 'correctness' category of lints are 'deny' by default. This is
the only clippy lints we want to enforce for now. The other ones we just
want to print in the logs. So remove any --deny and --allow arguments.
See discussion in #1410.
Run the linter on the minimum supported rust version; otherwise we will
get lint warnings for things that require a too high Rust toolchain
version to fix.
Allow the following checks, since we already violate them our code:
- clippy::new-without-default
- clippy::match-bool
- clippy::if_same_then_else
Eventually we should fix these lint issues and then disallow them to
prevent them from coming back in other places.
The clippy args used is recommended here:
https://github.com/rust-lang/rust-clippy#travis-ci
