When stamping is on (with --config=release), the version number in the packages will reflect the git tag. Otherwise, the version number will be 0.0.0 so that build caching remains unaffected by git details.
Relatedly, we change the output of stamp.sh when not building from a release tag. Previously it would output the full git hash (e.g., 8f5d7bc98b54d78b96780837887d83abd9a864d6), which is not a valid version number in many packaging systems (e.g., it might start with a letter instead of a number) and doesn't have good version-comparison properties. Now, we use the nice logic in git describe to end up with e.g. v1.19.0-9-g8f5d7bc so that it's based off of the git tag, but still reflects how many commits past we are, and still concludes with the (short) git hash for precision.
My hope is that future releases of bazelisk will upload these two new artifacts as GitHub release attachments, at which point I could also update this project's documentation to mention their availability.
(In an ideal world, these Debian packages would also be uploaded to the Bazel apt site documented at https://bazel.build/install/ubuntu#install-on-ubuntu, but at least having them as attachments here would be a good start.)
The new outputs are in a separate package (//deb) so that they are easy to skip over when not wanted (e.g., bazel build //:all will not even load the rules_pkg dependency).
Why are Debian packages useful? On Debian and platforms derived from Debian (Ubuntu, etc.), *.deb files are the nominal way to manage versioned software that's installed system-wide (in /usr). Instead of asking users to "... download Bazelisk binary ... and add it to your PATH manually ..." (which many users will struggle to accomplish), we can give them a package format they are already familiar with. This will ease the onboarding of new developers who want to use Bazel but struggle to get it installed properly.
Add rules to create Debian packages.
There are two new outputs to the build:
bazel-bin/deb/bazelisk-amd64.debbazel-bin/deb/bazelisk-arm64.debWhen stamping is on (with
--config=release), the version number in the packages will reflect the git tag. Otherwise, the version number will be0.0.0so that build caching remains unaffected by git details.Relatedly, we change the output of
stamp.shwhen not building from a release tag. Previously it would output the full git hash (e.g.,8f5d7bc98b54d78b96780837887d83abd9a864d6), which is not a valid version number in many packaging systems (e.g., it might start with a letter instead of a number) and doesn't have good version-comparison properties. Now, we use the nice logic ingit describeto end up with e.g.v1.19.0-9-g8f5d7bcso that it's based off of the git tag, but still reflects how many commits past we are, and still concludes with the (short) git hash for precision.My hope is that future releases of
bazeliskwill upload these two new artifacts as GitHub release attachments, at which point I could also update this project's documentation to mention their availability.(In an ideal world, these Debian packages would also be uploaded to the Bazel apt site documented at https://bazel.build/install/ubuntu#install-on-ubuntu, but at least having them as attachments here would be a good start.)
The new outputs are in a separate package (
//deb) so that they are easy to skip over when not wanted (e.g.,bazel build //:allwill not even load therules_pkgdependency).Why are Debian packages useful? On Debian and platforms derived from Debian (Ubuntu, etc.),
*.debfiles are the nominal way to manage versioned software that's installed system-wide (in/usr). Instead of asking users to "... download Bazelisk binary ... and add it to your PATH manually ..." (which many users will struggle to accomplish), we can give them a package format they are already familiar with. This will ease the onboarding of new developers who want to use Bazel but struggle to get it installed properly.