Adding github actions

[tarioch]

• tagging of pr
• release notes
• tests and publishing to pypi

[tarioch]

@johannesjh I started using the github actions infrastructure for some other projects and I really find them useful as it automates most things.

The way I setup things:

pr are automatically labeled with chore, bugfix or feature based on the branch name. If automatic labeling doesn't match, labels can manually be added

Release notes based on the PR are automatically generated

On pushes, tox is run and it tries if it can build a pypi package

On master a package is pushed to test pypi

On releases a release with the correct version is pushed to pypi

For this to work there is a small piece left that I don't have the permissions for. You need to go the the project settings and add two secrets

pypi_password and test_pypi_password and put in a pypi api toke generated on pypi/test pypi (on your account page)

[tarioch]

@yagebu would it be ok with you if I would drop the travis build and replace the badge in the readme with the one pointing to the action?

[johannesjh]

awesome!

[yagebu]

I removed the Travis badge - since we don't even use Travis anymore.

[tarioch]

The build and publish pipeline is already conditional, only running the publishing on master/tags. For me it makes sense to keep this in a pipeline as it should only publish if the tests pass. I'm ok to drop the other actions if you don't like them. I personally really like to use github releases for keeping track of changes (e.g. I use them on https://github.com/tarioch/beancounttools/releases). But I think this really boils down to personal taste. What do you think @johannesjh ?

[yagebu]

The build and publish pipeline is already conditional, only running the publishing on master/tags. For me it makes sense to keep this in a pipeline as it should only publish if the tests pass.

I saw that - but I think that those are testing and building are quite different things and should be two "checks" and jobs. Separate jobs can still be in a pipeline: https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds

I personally really like to use github releases for keeping track of changes (e.g. I use them on https://github.com/tarioch/beancounttools/releases). But I think this really boils down to personal taste.

I've had to deal with the useless UI of GH releases too many times to try to figure out what changed in some version that's now on page 20 of the releases. A plain CHANGELOG or CHANGES is much more accessible and doesn't have us depend on a proprietary solution.

[tarioch]

Reduced this pr to only do the build and release and split that into two jobs, although I prefer the one job approach as this has more duplication as each job runs on an own container you have to redo multiple steps on the publish job

[yagebu]

although I prefer the one job approach as this has more duplication as each job runs on an own container you have to redo multiple steps on the publish job

I've changed it back to that. Since we should build the release on every commit (if we release it automatically) that definitely reduces duplication :)

I've added the Sourcehut builds back, and will fix the job and step descriptions up a bit.

[yagebu]

I've also added a secret for PyPI and will merge this once I've found time to do the same for Test PyPI

[yagebu]

Thanks @tarioch!