Include version number in release archive names

[tobbez]

Summary

Add a release's version number to the names of archives containing binaries that are attached to that GitHub release.

This makes it possible for users to easily tell archives from different downloaded releases apart.

See also: #8961

Test Plan

The workflow was tested in my fork. The example release can be found at: https://github.com/tobbez/ruff/releases/tag/v0.1.7.

To allow the workflow run to succeed in the fork while testing, I had to use a small commit to prevent interaction with external services (ghcr, PyPI, and the ruff-pre-commit repository):

diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml
index 86eac6ebc..56b9fa908 100644
--- a/.github/workflows/release.yaml
+++ b/.github/workflows/release.yaml
@@ -463,10 +463,12 @@ jobs:
       id-token: write
     steps:
       - uses: actions/download-artifact@v3
+        if: false
         with:
           name: wheels
           path: wheels
       - name: Publish to PyPi
+        if: false
         uses: pypa/gh-action-pypi-publish@release/v1
         with:
           skip-existing: true
@@ -517,6 +519,7 @@ jobs:
           tag_name: v${{ inputs.tag }}
 
   docker-publish:
+    if: false
     # This action doesn't need to wait on any other task, it's easy to re-tag if something failed and we're validating
     # the tag here also
     name: Push Docker image ghcr.io/astral-sh/ruff
@@ -575,6 +578,7 @@ jobs:
   # After the release has been published, we update downstream repositories
   # This is separate because if this fails the release is still fine, we just need to do some manual workflow triggers
   update-dependents:
+    if: false
     name: Update dependents
     runs-on: ubuntu-latest
     needs: publish-release

Those workflow jobs are however not modified by this PR, so they should not be affected.

[charliermarsh]

This looks reasonable to me and seems to match the scheme that @BurntSushi uses in ripgrep. I really appreciate that you went through the effort of actually testing this, and have included the example release link in the PR.

[charliermarsh]

Above, tag says "The version to tag, without the leading 'v'. If omitted, will initiate a dry run (no uploads)." Do you know if that's still true? Can it be omitted? And, if it is omitted, what happens here?

[tobbez]

It can still be omitted, in which case ${{ inputs.tag }} expands to an empty string. That specific example would result in ruff--x86_64-apple-darwin.tar.gz in dry-run mode. You can see an example in this workflow run.

[charliermarsh]

It'd be nice to omit the second dash, but that's just a debugging workflow so not critical.

[BurntSushi]

One note to consider here is whether there are any docs anywhere that walk someone through downloading and extracting a release archive. Those might need to be updated to reflect the name change.

[tobbez]

One note to consider here is whether there are any docs anywhere that walk someone through downloading and extracting a release archive. Those might need to be updated to reflect the name change.

The installation instructions don't mention these archives at all, and a grep for zip and tar.gz in the repository found nothing relevant.

[charliermarsh]

Thanks @tobbez! Great PR.