[Disclaimer: I'm not an expert, just a random person walking through, so I may be way off]

@emcruise I think you need to change the tag_name with each release.

When you create the first release, it creates a tag that references the latest commit.
When the next release is created, since the tag_name didn't change, the tag already exists, and the new release points at the already existing tag/commit.

@movermeyer I kinda get your point and would agree that this is the behaviour of git. But I would disagree on the behaviour of the action. It should remove the release if it is called upon with a tag_name that matches an existing release.

I.e. the release with the name latest should always be latest and sure latest will exist in most cases. And this is where I see @emcruise `s point and would call this an unexpected behaviour / event.

This action could delete the previous release that is pointing at the latest tag, and generate a new one.
The action would also have to delete the latest tag. Otherwise using latest as the tag_name again will point to the same Git commit.

Depending on your project, people may or may not be OK with the deletion of tags. Often tags are expected to be immutable.
Though I suspect most projects would be fine adding exceptions for things like latest, nightly, etc.

My guess is that for that reason, if added it would be desirable to make it an optional flag. Something like:

- name: Release
      uses: softprops/action-gh-release@v1
      with:
        tag_name: latest # or nightly, etc.
        move_existing_tag: true # Explicitly opt-into the tag re-creation, since it would be bad to accidentally delete most tags

As pointed out by @Hu1buerger, deleting an existing tag and recreating it would also enable nightly builds. 👍

The current behavior is to update a release when attempting to create a release of the same version.

For something like an automated nightly release you may want a tag that reflects the date so that you can compare one release to another

Spitballing as I work through a similar workflow here, but rather than adding dates to your tags,

• Since GH derives the release date from the tag creation date
  • I think the creatordate from git tag -l --sort=-creatordate --format='%(creatordate): %(refname:short)'
• Since the action's current behaviour makes sense in a lot of contexts
• Since the action updates the release based on tag name, without checking if the tag has changed

It seems like you could accomplish what you want by "moving" the tag (deleting and recreating it) before running the release action, ex:

jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    steps:

      - name: Update release tag
        run: |
          git tag -d linux-latest
          git push origin :refs/tags/linux-latest
          git tag linux-latest
          git push origin linux-latest

      - name: Release
        uses: softprops/action-gh-release@v1
        with:
          tag_name: linux-latest
          files: |
            client/dist/client

If you follow the @christhekeele example, don't forget to add the missing actions/checkout before using the git command or it would fail.

If you don't want the job to fail when the tag doesn't exist, just add || true to the first 2 git commands.

Here is an extract of my workflow:

env:
  dev_tag: dev-build

jobs:
  build:
    uses: ./.github/workflows/build_artifacts.yml
  release:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v3
      - name: Downloads artifacts
        uses: actions/download-artifact@v3
        with:
          path: bin
      - name: Update dev-build tag
        if: ${{ github.event_name == 'push' }}
        run: |
          git tag -d ${{ env.dev_tag }} || true
          git push origin :refs/tags/${{ env.dev_tag }} || true
          git tag ${{ env.dev_tag }}
          git push origin ${{ env.dev_tag }}
      - name: Create dev-build release
        uses: softprops/action-gh-release@v1
        with:
          generate_release_notes: true
          files: bin/*/uad_gui-*
          prerelease: true
          tag_name: ${{ env.dev_tag }}

Here is the whole workflow if it can be useful to someone. I'm pretty happy with it

The current behavior is to update a release when attempting to create a release of the same version.

For something like an automated nightly release you may want a tag that reflects the date so that you can compare one release to another

@softprops The problem with this solution is that the releases would be flooded with nightly releases (for example if a nightly is created for every commit)
I would like to implement a solution like the workflows above directly in this action. Would you accept such a pull request ?

EDIT : The above workflows also miss the case where the release if populated with different workflows, I intend to fix that by checking if the commit associated with the tag is the commit the CI was run on, before deleting the tag, with an option like :

update_time_on: always|commit|never

never being the default

EDIT 2 : Release time is directly inferred from the commit of the release tag, so boolean value it is !

@iTrooz Please implement your feature recommendation, it would be very usefull to me!

In the end, I realized that I also wanted to move the release above others, so I will create a second option for that soon (by re-creating the release)