Repository navigation
Infra: consider using GitHub Actions?聽#186
Description
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.
Activity
s-celles commentedon Nov 9, 2019
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 commentedon Nov 9, 2019
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 commentedon Nov 10, 2019
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
blacksearches for the filepyproject.tomlfor 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.s-celles commentedon Nov 10, 2019
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 commentedon Nov 10, 2019
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 commentedon Nov 10, 2019
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:
release/2.9.5branch, for example.2.9.5. This string needs to be available in every file which contains a version string (setup.py,CHANGELOG.rstetc.)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 commentedon Nov 21, 2019
@scls19fr would you be ok if I start with a GH Action calling the
blackformatter? 馃槆 馃槉s-celles commentedon Nov 21, 2019
Absolutely @tomschr you can!
Sorry for not answering before... I'm currently very busy.
Extend python-semver#186: Add GitHub Action for black formatter
Extend python-semver#186: Add GitHub Action for black formatter
Extend python-semver#186: Add GitHub Action for black formatter
Extend #186: Add GitHub Action for black formatter (#200)
tomschr commentedon Nov 24, 2019
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.