GitHub Actions

[The-Compiler]

I got into the GitHub Actions Beta with my account, and the mail I got mentioned it was enabled for @pytest-dev as well!

So we could use GitHub Actions for a variety of things now:

• CI (instead of e.g. Travis)
• Workflow automation - see e.g. the examples here: https://github.com/actions/starter-workflows/tree/master/automation

I'll probably start experimenting a bit with qutebrowser and maybe (if nobody beats me to it) implement a Python library to write GitHub actions!

(However, it'll likely take me a while, last exam coming up next week, and then some holidays!)

[nicoddemus]

Yep, I've received it this week as well.

Some ideas I have for awhile where we could use this:

1. Run tox -e regen linting after each merge to master or features, and if there are changes, opening up a PR. This would help catch problems in regen sooner than at release time. 👍

2. On workflow automation, merge master into features periodically or perhaps after each merge to master.

[RonnyPfannschmidt]

Also opening up prerelease branches from master and features, and merging them after tag and release happen

[nicoddemus]

Also opening up prerelease branches from master and features, and merging them after tag and release happen

With this, my 1) is unnecessary then. 😁

[RonnyPfannschmidt]

@nicoddemus your 1) is orthogonal to that, i'd love if the release proposal pr was limited to only running towncrier

[nicoddemus]

Well, if every merge will open a potential release PR, it would by definition need to include a tox release anyway, that's why I think it is unnecessary.

The release process needs to run tox release to ensure all bits are in place, we don't want to have regen and release in separate PRs as this opens up the chance of they getting out of sync.

[RonnyPfannschmidt]

good point, so it be

[The-Compiler]

A list of potentially interesting GitHub Actions: https://github.com/sdras/awesome-actions

[nicoddemus]

Just to drop a few ideas that occurred to me today after thinking about the new workflow and using again the excellent web services from conda forge.

We could automate some things of the new workflow:

• Add a label to PRs to automatically backport bugfixes from master to the latest bugfix branch. The workflow would then cherry-pick the PR into a new branch, open a PR targetting the bugfix branch, and merge it once the build passes. It could even finally add a "ported to 5.3.x" comment to the original PR.

• Prepare a new release by creating a new issue or posting a new one stating a phrase like "@pytestbot please prepare release 5.3.0".

[bluetech]

Such automation would be nice.

Regarding the backports, I think it would still be best to have a human approve and merge the generated PR, just to double check and possibly amend.

Also, pull requests in GitHub must come from some GitHub repo/fork as far as I know. I wonder which one it should be? One option is to use the main repo, but that will get messy. Another option is to create in a fork under the @pytestbot user if that's possible to do.

[hugovk]

If you need to do stuff to the main repo that needs certain permissions using GITHUB_TOKEN, or other secrets, that may be impossible from forks and you'll need to do it from a main repo branch.

See things like:

• https://github.community/t5/GitHub-Actions/Token-permissions-for-forks-once-again/td-p/33839
• https://github.community/t5/GitHub-Actions/Make-secrets-available-to-builds-of-forks/td-p/30678
• And the need to hardcode the Codecov token: Implement code coverage in GitHub actions #6441, Include codecov on GitHub Actions #6421 (comment)

[nicoddemus]

Regarding the backports, I think it would still be best to have a human approve and merge the generated PR, just to double check and possibly amend.

Probably it wouldn't be needed, our 4.6 maintenance branch guidelines stated that if the backport applied cleanly and the build passed, it could be merged without a review. I think this would work the same here.

One option is to use the main repo, but that will get messy.

One way to make it less messy is to make the bot use a prefix, say create all branches with the bot/ prefix.

[The-Compiler]

I suppose this can be closed, as we're using GitHub Actions for various stuff nowadays 😄