release: Use GitHub Actions for manually triggered builds and artifact uploads

[JoeKar]

The release will by default include the description (title and body) of the tag used as input (in case of a manual trigger).

This will add one more option to create the release, besides the fully manually approach where the artifacts must be build locally and uploaded afterwards. We can then just start the action with the tag by Use workflow from and the GitHub sandbox will create all artifacts and attach it to the release. No local resources are needed.

Fixes #3322

[dmaluka]

We can then just start the action with the tag by Use workflow from

Could you point at where it is?

Also almost off-topic: what's going on with https://github.com/zyedidia/micro/releases/tag/nightly ? Why are there are not just the up-to-date micro-2.0.14-dev.231 artifacts but also
micro-2.0.14-dev.181 artifacts (built from an April's version, and without SHA sums, but it says "19 hours ago")?

[JoeKar]

We can then just start the action with the tag by Use workflow from

Could you point at where it is?

Only via the nightly as example, since the workflow will be available first in the moment it's merged to the master. But it will then look like this:

Also almost off-topic: what's going on with https://github.com/zyedidia/micro/releases/tag/nightly ? Why are there are not just the up-to-date micro-2.0.14-dev.231 artifacts but also micro-2.0.14-dev.181 artifacts (built from an April's version, and without SHA sums, but it says "19 hours ago")?

Hm, from my point of view it was obvious that we can't solve this without the help of @zyedidia, since he needs to stop his (cron?) triggered nightly build. See also #3334 (comment) & starting from #3334 (comment) downwards.

[dmaluka]

Thanks. Regarding @zyedidia's cron job - yeah indeed, somehow I missed that discussion or forgot about it, and I hadn't noticed this weirdness myself until yesterday.

[dmaluka]

Probably LGTM. I'm assuming you've tested this in your fork?

[JoeKar]

Yes, I run it there with a custom tag I created.

[JoeKar]

The first test with v2.0.14-rc1 showed me, that it is maybe better to set generate_release_notes to true by default:

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 for more information

Because the auto generated change history seems to sum it up the best by listing all PRs automatically.
If we don't like it we only need to delete/edit the body of the created release.

Right now we've to edit the created release and have to click on a button.

What do you think?

[dmaluka]

I.e. v2.0.14-rc1 was created with generate_release_notes already enabled?

Ok, let's enable it. I think this automatic description is not good enough, it just dumps everything without emphasizing/summarizing major changes interesting to users, but let's have it by default and edit it as we see fit.

Or maybe no need to enable it, since we already have this generated for v2.0.14-rc1 so we can just copy it to v2.0.14.

BTW before v2.0.14 we can take some time to turn this into a good summary (e.g. at least remove unnecessary tiny details like "ReHighlightStates: sanity-check startline value by @dmaluka").

[JoeKar]

I.e. v2.0.14-rc1 was created with generate_release_notes already enabled?

No, I clicked on that option while modifying the release name etc.

I think this automatic description is not good enough, [...]

Depends on the perspective.
It's flooding, indeed, but no contributor is missed and it's complete. The list gets longer in case too much time resp. PRs pass by between the releases.
It can be reduced to the major changes at any time.

Seems like a matter of preferences what should be the default.
I was interested in your expectation when you use the action to create the release. 😉

At least the title needs to be manually modified anyway, since this doesn't fit to the current "scheme".

[dmaluka]

I was interested in your expectation when you use the action to create the release. 😉

It would barely make any difference to me. :)