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.
