Update GitHub Actions

[BelleNottelling]

This pull request updates your GitHub actions as they were out of date and throwing deprecation warnings (with one likely to stop working in the near future)

You'll notice I switched the release action from marvinpinto/action-automatic-releases to ncipollo/release-action.
I did this because the current one doesn't really seem to be actively maintained and it's using set-output, which is deprecated and soon to be removed by GitHub.

I've also left the usage of the secret in for the release action, however it's actually not needed per the action's docs. (this is also how I tested it)

Also, this action does have a few caveats compared to the one you are currently using:

• It doesn't really seem to generate release notes, so I just opted to use the commit message for the release body
• It doesn't update the source code artifacts when updating a release
• The commit SHA / Tag doesn't seem to get updated, so GitHub will show "X commits to master since this release" even though it'll be the latest

Test release I made is here: https://github.com/BelleNottelling/v86/releases/tag/latest

[copy]

Thanks!

I've also left the usage of the secret in for the release action

Let's remove that then.

It doesn't update the source code artifacts when updating a release

What does this mean? Isn't there always exactly one release, with the latest artifacts (and older artifacts are deleted)?

The commit SHA / Tag doesn't seem to get updated

That seems a bit confusing. Are you sure the artifacts are built from master and not from the tag? Couldn't we specify commit: master to update the tag from master?

[BelleNottelling]

Let's remove that then.

Done :)

What does this mean? Isn't there always exactly one release, with the latest artifacts (and older artifacts are deleted)?

Yeah, but it's only updating the release and it's not deleting / re-creating it. So you end up in a situation like this:

That seems a bit confusing. Are you sure the artifacts are built from master and not from the tag? Couldn't we specify commit: master to update the tag from master?

I don't think it updates the tag at all, so no matter what the tag will be out of date. I did try doing commit: master, however the behavior ended up being the same. The built artifacts do get update though, I have a similar workflow in a project of mine.

Maybe there's another action that'll do what we want, or we could delete the tag and release so that it'll always create a new one?

I took a look at what NooDS does and they are using this https://github.com/dev-drprasad/delete-tag-and-release to delete the tag and old release, so their project doesn't have that issue. However, it does look like deleting the tag & release needs a token with write permission to the repo.

[copy]

However, it does look like deleting the tag & release needs a token with write permission to the repo.

I think that's fine.

Or, alternatively, follow these steps: marvinpinto/actions#695 (comment)

[BelleNottelling]

However, it does look like deleting the tag & release needs a token with write permission to the repo.

I think that's fine.

Or, alternatively, follow these steps: marvinpinto/actions#695 (comment)

I think I'd rather just go with the 1st option, especially since I looked back and realized that NooDS seems to be using the default GitHub token to remove the tag & release. I'll give a test locally and if all is good I'll update the PR and let you know

[BelleNottelling]

@copy I have pushed a new update which fairly significantly improves the release workflow. The following changes have been made:

1. It now runs for both pushes to master as well as PRs open to it. (No release will be made, modified, or deleted unless it's actually a commit to master)
2. As part of point 1, artifacts are now made available so it's actually rather easy for someone to test a PR as they can just download the built artifact from it
   
3. I've removed the cache step for the rust toolchain as it wasn't working.
   a. I'm not convinced it's ideal to be caching the binary of the toolchain and potentially automatically building it on an outdated version
   b. I switched it to the minimal profile, so the install is a bit smaller
   c. There's actually a rust specific cache action which is kinda cool but it focuses on deps which we have none here.
4. It (somewhat) correctly deletes the old release and tag before publishing a new one.

I say somewhat correctly as I noticed it left a draft release behind. However it does at least publish the new one correctly. To be honest, I have no idea why that is happening & in my initial testing it was actually producing only draft releases, but it started publishing them correctly when I made some further changes to the workflow.

This can be pretty easily worked around by using an action like this: https://github.com/hugo19941994/delete-draft-releases, but wanted to ensure you were aware of that before adding an automated workflow that might nuke any drafts you had created,

Anyways, looking forward to any feedback on these changes & thoughts about the odd draft release behavior.
Cheers!

[copy]

Excellent, thanks!

Are draft releases only visible to owners of the repo? I think I'll delete them manually every now and then.

I think this is good to merge as is, but there is one more addition that would be nice to have. Now that build runs on every PR and commit, it would make sense to merge the two workflows, and upload only after tests pass. That way, we save one build, and don't get artifacts of failed tests.

[BelleNottelling]

Are draft releases only visible to owners of the repo? I think I'll delete them manually every now and then.

Correct :)

Now that build runs on every PR and commit, it would make sense to merge the two workflows, and upload only after tests pass. That way, we save one build, and don't get artifacts of failed tests.

Just to make sure I'm understanding correctly, do you mean to merge the release and tests workflow into one, ensuring that the release portion of the workflow is performed if the tests pass? I can certainly make that happen

[copy]

Just to make sure I'm understanding correctly, do you mean to merge the release and tests workflow into one, ensuring that the release portion of the workflow is performed if the tests pass?

Yes

[BelleNottelling]

Okay, @copy That's all done now.
The two workflows are merged into one & I also did some minor cleanup to what was in the tests workflow

[copy]

Thanks!

[BelleNottelling]

Welcome!