Release time does not update

expected behaviour

I expected that when i generate a release through GitHub-Actions as such:

on:
  push:
    branches: [ main, release-publish ]
  schedule:
    - cron: "* */6 * * *"
[...]
    - name: Release
      uses: softprops/action-gh-release@v1
      with:
        tag_name: linux-latest
        files: |
          client/dist/client

that the release which is generated points to the commit which triggered the action and the time of the push.

actual behaviour

The assets of the release are the correct after the workflow run, but the release points to the wrong commit and therefore states a wrong time.

Issue in more detail

In my project I have a cron job, which regularly updates my releases. Even though the assets change correctly the release states a wrong time and points to a wrong commit, which can be seen here. The wrong time could result to me living in a UTC+1 time zone which could give my commits a wrong time, but this still doesn’t explain why the release points to the wrong commit. When I delete the releases and regenerate them through GitHub-Actions they work correctly and point to the correct commit with the correct time.

[iTrooz]

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

[movermeyer]

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. 👍