Release time does not update

[emcruise]

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.

[movermeyer]

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

[hu1buerger]

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

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

[softprops]

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

[christhekeele]

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

[0x192]

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

[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

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

[emcruise]

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

[iTrooz]

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)