Add an automatic build tool

[logileifs]

We want to have a tool like rultor to automate build and release as much as possible

[gsailer]

What about using TravisCI for deployment as well? You can configure travis so that it automatically deploys to PyPi as soon as a new tag is created.

For further reading see: http://5minutes.youkidea.com/howto-deploy-python-package-on-pypi-with-github-and-travis.html

[logileifs]

@sublinus It's an option, can a Travis job be triggered to run after a pull request is merged?

[logileifs]

I'm thinking of automating the release of a new version to PyPi as soon as a pull request has been merged. I know rultor can be triggered with a comment from pull request

[gsailer]

Afaik travis builds are run on new PRs and on commits to the repo. As a merge is a commit, the merge should trigger a travis build and thus deploy if the option is enabled.
To note is that a PR build does not trigger deploys as seen here.

[gsailer]

That way you would not even have to comment on the PR but just merge.
Important for that is that in the deploy section of the .travis.yml tags: true is not set.

[logileifs]

@sublinus so you propose we tag each merge commit with an incremented version number which would then trigger a travis build job to release the new version? Do you know how we would handle credentials for PyPi authentication with Travis?

[gsailer]

The credentials are encrypted in the .travis.yml as seen in the docs. Yes that would mean that the version would have to be iterated on each pull request. But I think it is better to release with new git tags. With that there would be release notes hosted on github and release history available as well. The github release function creates tags. And travis deploy has the option to release on new tags.
Do you want to iterate the version hosted on pypi with every PR merged?

[logileifs]

@sublinus well ideally there should always be a feature request or a bug that triggers a pull request so in most cases it should result in a new version being built. But it should be a human that decides if a new version should be built or not and therefore I was thinking about rultor

[gsailer]

It definitely is a good idea to let a human decide if a new version should be built and deployed. The benefit of using travis here(with tags: true - meaning that a deploy build is triggered when a github release is made) would be the version history on github with release notes, if desired.

This would add the task of adding a new release on github to the merging of a PR and thus would not be as easy commenting below the PR, but i think it's more desirable on the long term because releases become more transparent to users, especially with the releases and release notes informing users about changes available on github.
Furthermore you can also use the environment variable TRAVIS_TAG[1] in the setup.py to automatically insert the version number that was set on the github release. That way contributors don't need to change the version number every time a new release is made and you can control versioning on your own without adding unnecessary commits.

[1] https://docs.travis-ci.com/user/environment-variables/

[gsailer]

An example of use of travis as described above can be found here: https://github.com/sublinus/sptygenre/blob/master/.travis.yml

In this case the version is replaced by the tag-name that triggered the travis build. Builds with deploys are triggered by adding a new release on the Github website.