add 'update_tag' option #293
Conversation
|
I need this feature for continuous releases . @softprops How can I help test this ? |
|
@softprops Can you please take a look here finally? This is a very useful feature and our project would highly benefit from it. Thank you very much! |
|
@iTrooz can you fix the merge conflicts? Thanks! |
|
@iTrooz ping |
|
Hey, unless the maintainer shows interest in merging this, I'm not interested in updating it, sorry |
|
Oops, I just realized that you are a maintainer of this repository. I will update this PR soon |
|
yeah, please :) |
|
Why did I think making a refactor on a feature PR was a good idea.. Anyway, done ! Note that I have no idea how github orders release, using |
|
@chenrui333 Ready for review/merge I already tested this PR, but if anyone wants to double-check, please do so |
|
|
||
| // give github the time to draft the release before updating it | ||
| // Else, I think we would have a race condition with github to update the release | ||
| await sleep(2000); |
There was a problem hiding this comment.
There is something inherently unreliable and inefficient about relying on time as a synchronization primitive
It’s possible that sleeping 2 seconds isn’t long enough resulting in a noneffective approach and it is also possible that is is way to long resulting in wasted gh action time.
Is it possible to restructure this without so that it’s not time dependent?
There was a problem hiding this comment.
I fully understand why sleeping is not a perfect solution.
That said, this is certainly the easiest option to implement.
Another solution that could work would be to make a request to the github API every second to check if the draft was done yet. Would you prefer this ?
| @@ -194,6 +194,7 @@ The following are optional as `step.with` keys | |||
| | `generate_release_notes` | Boolean | Whether to automatically generate the name and body for this release. If name is specified, the specified name will be used; otherwise, a name will be automatically generated. If body is specified, the body will be pre-pended to the automatically generated notes. See the [GitHub docs for this feature](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes) for more information | | |||
| | `append_body` | Boolean | Append to existing body instead of overwriting it | | |||
| | `make_latest` | String | Specifies whether this release should be set as the latest release for the repository. Drafts and prereleases cannot be set as latest. Can be `true`, `false`, or `legacy`. Uses GitHub api defaults if not provided | | |||
| | `update_tag` | Boolean | Update the tag of the release to the current commit. This will also update the release time. Default is false | | |||
There was a problem hiding this comment.
I have some reservations about this. Action gh release is an action for managing GitHub releases, the product feature
the concern is that with these changes the scope is increasing to also include managing git state something that feels possible with git itself external to this action.
Would it be possible to do that as a separate workflow step or possibly trigger that then triggers the workflow that manages gh release data?
There was a problem hiding this comment.
It would definitively be possible to do this in another step, and I understand why this may be preferable to extending the scope of this action.
So at this point, it may be better to just use the solution described here : #171 (comment)
|
Closing in favor of #171 (comment) (See also #293 (comment)) |
This PR adds the 'update_tag' option
Fixes #171