Automation of release process

[MetRonnie]

This is just to brainstorm increasing the automation in releases.

Things that ought to be possible in GH Actions:

• [x] Automatically set the version number in __init__.py from the release version (although I guess you lose out on the review process if you make a mistake with the release?)
• [x] Automatically write the "released on" date in the changelog
• [x] Automatically update the copyright year
• [x] Upload the build to PyPI (not sure about authentication)

This could be triggered by creating a GH Release instead of pushing a tag (GH release creates the tag instead), which is how it's done on cylc/vscode-cylc and cylc/language-cylc

Anyone have any comments or other ideas?

Update:

• [x] Could we have it change milestones when an PR is merged earlier than expected, or comment to remind us?

[MetRonnie]

We could use https://github.com/pypa/gh-action-pypi-publish

[MetRonnie]

Question: how important is it that the commit that is tagged is verified? Usually the release tag is on a PR merge commit, which, performed on GitHub dot com is verified, but if you have GH Actions push a commit it isn't verified, and I assume you would have to set up some sort of GPG key thing in order for it to be...

If that makes any sense...

[kinow]

I think that should be OK, but @hjoliver or @dpmatthews might know if there's a security requirement for the release commit to be signed.

[oliver-sanders]

From previous discussion on Riot I think we should be happy to use the pypa GH action in combination with GH deploy keys for authentication.

although I guess you lose out on the review process if you make a mistake with the release?

How about using a GH action to create a pull request with the changes (version number, copyright year, etc), then firing a deployment action off of that PR?

[MetRonnie]

Something I just found out about GH actions: when you have

on:
  pull_request:

and you use actions/checkout, that doesn't exactly check out the PR branch - it actually creates a merge commit (PR branch into master (or whatever the base is)) and checks out that merge commit, locally on the runner. This is actually what Travis does as well.

[MetRonnie]

Some features I wish Actions had, but doesn't:

1. The ability to trigger on a particular PR branch name. Currently you can only trigger off the base branch name using

   on:
     pull_request:
       branches: [master]

   You can however use an if on the job,

   jobs:
     check-release-pr:
       if: startsWith(github.head_ref, 'prepare-')

   but it means the workflow will still be triggered, showing up in the repo's Actions page for every pull_request event (albeit with a grey icon indicating "skipped").

2. (In combination with the previous point) The ability to trigger when a particular PR is merged. Currently the only way to do this is

   on:
     push:
       branches: [master]

   which again indiscriminantly runs (even if "skipped").

   Update: you can also do

   on:
     pull_request:
       types: [closed]
   
   jobs:
     job-name:
       if: github.event.pull_request.merged == true

3. Some sort of manual trigger. Perhaps you could go into the repo's Actions page and click a button to trigger a fresh run of a particular workflow on master.

[MetRonnie]

Note that github.head_ref is just the branch name, unlike github.ref it doesn't include stuff like refs/head/..., nor does it include whether the PR branch is on the base repo or a fork

[MetRonnie]

3. Some sort of manual trigger

Well well: https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/

[MetRonnie]

Note: when you set the if condition on a workflow step to some custom expression, it's implicitly if: success() && <expression> unless the expression contains one of the status check functions [success(), failure(), always(), cancelled()]