Skip to content
This repository has been archived by the owner on Mar 4, 2021. It is now read-only.

Is it possible to avoid duplicate tag? #72

Open
vincentwongso opened this issue May 25, 2020 · 5 comments
Open

Is it possible to avoid duplicate tag? #72

vincentwongso opened this issue May 25, 2020 · 5 comments

Comments

@vincentwongso
Copy link

First I just want to say thank you for this great github action plugin.
I am having this issue whenever I am creating a PR against release branch I use this action to create release draft and automatically create a tag based on the PR title. But whenever I pushed new changes to the same branch where I create PR from, it automatically create a new release draft with the same tag.

Is there a way to avoid duplicate release tag in this action? So if there is already a release with the same tag, it should just not create new release.
So maybe an option like:

avoid_duplicate_tag: true
@nerdCopter
Copy link

nerdCopter commented Jun 7, 2020

i agree, the readme example reports On every push to a tag matching the pattern v*, create a release. so, one would think that when pushing a tag, this action would use the existing release that the tag created. additionally, i would want this to modify it to be a draft so that it's not a public release until i decide it such.

@coot
Copy link

coot commented Jun 12, 2020

This is also a problem when one needs to release multiple assets from different build machines. Github has get-a-release-by-tag-name api which could be used to verify if there is an existing release for the given tag already.

@nerdCopter
Copy link

nerdCopter commented Jun 12, 2020

@coot this is likely an improper forum to share, but i used softprops/action-gh-release@v1 to make a single draft from a matrix. it does not use re-use the tag that triggers my builds, but i can suffice by just deleting the triggering tag afterward.

@coot
Copy link

coot commented Jun 12, 2020

@nerdCopter thanks for your suggestion. I solved this by using: action/upload-artifact in the builder job, and using another job that depends on the previous one which is creating the release and using action/download-artifact& action/upload-release-asset. This way there's only one job that creates the draft release and all assets are attached to it.

@nerdCopter
Copy link

Agreed. i did this also, then preferred the other method. both work very well. the nice part is you can use the need: id when you break it into a secondary job.
These are good comments for future visitors, imho.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants