-
-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release time does not update #171
Comments
[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 When you create the first release, it creates a tag that references the latest 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 I.e. the release with the name |
This action could delete the previous release that is pointing at the Depending on your project, people may or may not be OK with the deletion of tags. Often tags are expected to be immutable. 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 |
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,
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 If you don't want the job to fail when the tag doesn't exist, just add 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 |
@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) 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 :
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) |
expected behaviour
I expected that when i generate a release through GitHub-Actions as such:
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.
The text was updated successfully, but these errors were encountered: