How to adjust automagic release naming by tag?

[tansy]

Select Topic Area

Question

Body

How to adjust automagic release naming by tag

This automagic release naming by tag is, for lack of better word, far-fetched and illogical.
How can one, and why is is not available, to control released archive and repository name?

Imagine one wants to issue a release of their program called progeny. Their repository is user/progeny and the program version and therefore tag put in release box is v1.2.
The released program archive will be called v1.2.zip (or .tar.gz), which doesn't mean anything.

Now user, taught by their first/previous release/s, wanted the file to have a more meaningful name, including a program name, put a full program and version name in a tag: progeny-1.2. Now the archive is concededly called progeny-1.2.zip but repository inside is called (sic!) progeny-progeny-1.2.

Why on Earth, can't it be called progeny-1.2.zip with progeny-1.2 inside? That would be logical. The way it is now - v1.2.zip with repository progeny-1.2/ inside - is not.

Can user control it?
If not, then can I ask for such a, de facto, trivial feature?

[EchoSingh]

By default, GitHub creates release archives with the tag name and places the repository contents in a folder named after the repository. For example:

• Archive name: v1.2.zip or v1.2.tar.gz
• Folder inside the archive: progeny-progeny-1.2/

This might not be logical for many users, especially when they want more meaningful naming like progeny-1.2.zip with progeny-1.2/ inside.

Possible Solutions

1. Pre-release Script (Manual Approach)

You can create a release script (e.g., a shell script) that:

• Tags the release.
• Renames the archive file and folder structure manually.
• Uploads the custom archive as a release asset.

Here’s an example of what the script might look like:

# Example shell script to manually create a release archive
git tag progeny-1.2
git archive --format=tar.gz -o progeny-1.2.tar.gz HEAD
# Optionally rename the archive or folder structure here
# Upload the resulting tar.gz file manually via the GitHub UI

2. Automating with GitHub Actions

You can create a GitHub Actions workflow to automate the release process. This way, you can control the naming conventions, including the archive name and folder structure.

Here’s an example GitHub Actions workflow (release.yml):

name: Release

on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Create custom release archive
        run: |
          # Create archive with desired structure
          mkdir -p release
          git archive --format=tar.gz -o release/progeny-1.2.tar.gz HEAD
          # Add your custom logic here to rename files or structure

      - name: Upload Release Asset
        uses: softprops/action-gh-release@v1
        with:
          files: release/progeny-1.2.tar.gz

This workflow:

• Triggers on a tag push: The workflow runs when a tag is pushed (v* matches version tags like v1.2).
• Creates a .tar.gz archive: It creates an archive of the code with the desired name and structure.
• Uploads as a custom release asset: The archive is uploaded as a custom release asset using the softprops/action-gh-release GitHub Action.

3. Feature Request

If this feature is essential for your workflow, consider submitting a feature request to GitHub:

• GitHub Community Discussions
• GitHub Support

[tansy]

Thank you for such detailed answer. It was this bad. All these hurdles to get such a simple thing.
I will test it but will try to reach Gh as well.

Uploads the custom archive as a release asset.

Sure I can do that, but it means adding another tarball to the basket. It also may be confusing, as well as unnecessary duplication and waste of resources. Mine and Github's.

consider submitting a feature request to GitHub

I thought I was on community discussion.
I chose 'question' as there was no other, reasonable choice. There could already be some setting to that as well.

If that means contacting Support then it's going to be painful.

[EchoSingh]

I completely understand your frustration. It feels like a simple request, but all the extra steps can make the process unnecessarily complicated. I agree that adding another tarball could lead to confusion and waste resources, both yours and GitHub's.

Reaching out to GitHub might indeed take some time, but it’s worth considering, especially if others are facing the same issue. You might also want to keep an eye on any potential updates to the community discussions or GitHub settings that could address this in the future.

I hope the script or GitHub Actions approach works out for you in the meantime. 👍