Infra: consider using GitHub Actions?

[tomschr]

Situation

Although GitHub Actions are still in public beta, it could be a helpful addition to this project in the future.

Ideas & Questions

Actually not any solution (yet), but some questions. 😉

Scope

I've opened this issue mere to collect ideas and discuss the pros and cons. It can lead to an implementation or that members decide to better reject this issue. Both would be fine for me. 😉

Currently, I don't see GH Actions as a replacement for the existing Web hooks for Travis or ReadTheDocs. They don't need to be replaced (although they potentially could). I see GH Actions more as an addition to simplify some specific workflows so that these workflows appear under one roof.

Additionally, if we need a specific workflow in the future, it can be usually added quite easily. Doing the same by creating a new Web hook and the respective infrastructure can be a bit more complicated.

Potential Use Cases

GH Actions are more than just "Travis CI". To name a few use cases:

• help with creating a release (see https://github.com/actions/create-release)
• help with creating additional assets when creating a release (for example, build automatically the documentation for each release and make it available as additional download in PDF or EPUB format; see https://github.com/actions/upload-release-asset)
• runs the black code formatter on the source code to maintain code style (see https://github.com/marketplace/actions/black-code-formatter)
• deploy automatically to Pypi after a successful build
• start automatic tasks every week/month, for example, to search for dead links, unsorted imports etc. and open new issues automatically. Like a weekly/monthly health report.

Of course, it is possible to create your own GH Actions: add a new repository to your organization and refer to it in the respective action config file.

---

Could that be a useful addition to our project?

Currently, I see the biggest benefits when creating new releases. When creating a new release, this usually involves some manual tasks which can be easily forgotten. With a GH Action this could be done automatically.

See also

1. https://github.com/features/actions
2. https://github.com/marketplace?type=actions
3. https://help.github.com/en/actions/automating-your-workflow-with-github-actions

[scls19fr]

Being able to publish release directly from Github will be a nice feature.

I was very interested in GitHub Actions when GH publish it publicly but I didn't had time (or didn't spent time) on it.

All your suggestions are very interesting maybe we should first try one usecase which could have not much "side" effects so it will be possible to later tackle harder usecases.

I personally like Black (Go have quite similar command for formatting automatically code: gofmt).

Maybe this could be a quite interesting use case which could be easily tested.

[tomschr]

I fully agree with you. 👍

I've played around a bit and it looks indeed quite promising. As you, I would go for a more cautious approach first and see how this will fit into the project.

Using black is a good idea. I can try to apply that in my fork...

[tomschr]

I've played with a black GH Action from jpetrucciani/black-check and it created this result in my fork. It was amazingly easy to create. Look for the entry "Format Source with Black".

This is an entirely separate GH Action, but it could be integrated into a bigger workflow. The Action or black searches for the file pyproject.toml for additional configuration of black. It could probably be adapted further to create issues automatically when black formatting returns an error. However, I didn't come that far yet.

[scls19fr]

I'm wondering if that's possible to automatically create a commit in a PR to fix code with black.
So, after GH Action have run, contributors could sync their branch with code formatted with black on server side ie without having black installed on their computer.

[tomschr]

That's an interesting idea! There is the actions/create-pull-request-easily Action which could done that job for you. However, I haven't tried it yet. 😉

[tomschr]

I've looked into release-procedure.md. It contains a lot of steps to create a release.

It seems, that this workflow could be covered by one or more GH Actions. That would make the creation of a release a less error-prone task and you cannot forget a step. Maybe something semi-automatic?

I could imagine one workflow like this:

1. User starts the workflow and creates a release/2.9.5 branch, for example.
2. GH Action checks for the release 2.9.5. This string needs to be available in every file which contains a version string (setup.py, CHANGELOG.rst etc.)
3. GH Action performs all the necessary additional checks that needs to be carried out.
4. GH Action responds with either "success" or "error". When there is an error we need to fix it, of course. If the Action responds with "success", the owners get notified to review it.
5. If one of the owners respond with "accepted", the branch is merged to master, receives a tag, and the wheel/sources are uploaded to PyPI.

I'm not sure if all would be possible, but I assume, this is a matter of permissions and the correct action. Just dreaming. 😉

[tomschr]

@scls19fr would you be ok if I start with a GH Action calling the black formatter? 😇 😊

[scls19fr]

Absolutely @tomschr you can!
Sorry for not answering before... I'm currently very busy.

[tomschr]

The black formatting is implemented in #200 now. We can add further GH Actions when needed in different issues, so I guess we can close this.