Delete old release

[vicr123]

Adding an option to replace an old tag if one exists. This should allow this action to be used (along with the upload-to-release action) to replicate the behaviour of https://github.com/probonopd/uploadtool on GitHub Actions.

[eine]

Hi @vicr123! The feature you wish to implement seems to be similar to 1138-4EB/tip. On the one hand, I'd like to ask if you know whether it's possible to avoid having notifications shown when a pre-release is published/updated. The use case is to have a tip, continuous or nightly release that is updated everyday, without triggering a notification to all the users/watchers of the repo. On the other hand, I think it is possible to update a release, instead of deleting it and creating a new one: https://octokit.github.io/rest.js/#octokit-routes-repos-update-release. You might find it useful.

[vicr123]

Hey @1138-4eb

The problem I see with updating releases is that the tag will not point to the correct commit and may end up showing behind stable builds. You probably also want to clear all the release artifacts anyway so I think deleting a release would be easier.

As for avoiding notifications when a prerelease is published, I can't say anything unfortunately. Maybe someone else can enlighten us 🙃

EDIT: 1138-4EB/tip seems to be exactly what I'm looking for. I'll give it a go at some point and decide which action to use :)

[eine]

The problem I see with updating releases is that the tag will not point to the correct commit and may end up showing behind stable builds. You probably also want to clear all the release artifacts anyway so I think deleting a release would be easier.

Although not required, you can provide tag_name and target_commitish as arguments to octokit.repos.updateRelease. Hence, I think that this should not be a problem.

However, I am not sure about artifacts. I.e., if you already uploaded artifacts and you the edit/update the release to point to the different tag, artifacts will no longer correspond to the tag, unless you update/overwrite all the artifacts too. That's why I just suggested to have a look at it, but I didn't propose you to change this PR.

As for avoiding notifications when a prerelease is published, I can't say anything unfortunately. Maybe someone else can enlighten us 🙃

I hope so. That's the main reason that is preventing me from considering 1138-4EB/tip stable. Currently, each push/PR triggers a notification, and it is so annoying. You can just ignore the repos, but when you are a maintainer you cannot do that.

EDIT: 1138-4EB/tip seems to be exactly what I'm looking for. I'll give it a go at some point and decide which action to use :)

Please, note that, because of the reason commented above, it is an experimental repository/action yet. It is not published to the marketplace, and there is no v1 branch or tag. Ideally, the functionality provided by 1138-4EB/tip should be merged in some official action (see eine/tip#17).

I am using it mostly as a playground to test the suggestions/contributions in official actions. For example, all the (multi-line) arguments to files are considered glob patterns. I use it to suggest modifications in actions/upload-artifact#3 (comment) and as a proof that having issues such as actions/upload-artifact#7 unattended is nonsense.

Currently, any push or PR will update branch gha-tip and tag tip, along with pre-release tip. Nonetheless, I'm successfully using it in 1138-4EB/issue-runner; thus, it works. Should you really want to use/test 1138-4EB/tip, please open an issue, and I will push a stable v0 branch.

[aesedepece]

I recently added actions/create-release in a scheduled GitHub action to witnet-rust with the aim of producing nightly builds at midnight, but we were facing the issue of the action failing if the commit-ish reference at master branch was the same for two nights in a row.

Just switched to a fork of this branch and it seems to work like a charm. Thanks @vicr123 for this! 👏