[IMP] Add CI integration

[lasley]

This PR adds CI:

• Travis
• Codecov
• Coveralls
• CodeClimate

Let me know if you don't want to use any of the above and I'll remove from the ReadMe. Once you enable Travis on your end, I will rebase so we know it works. Here's our build until then.

It also adds (disabled) docs generation to the gh-pages branch, and PyPy push if you want it. I'll comment inline for what we'll need to do to finish those though.

I also added two basic tests, mainly just so we know that CI is rigged up right. I didn't want to make the scope of this any larger than necessary.

Note that the setup.py is primarily automated now, which may not be desirable depending on how you do things. Let me know if that's the case & I'll switch back.

Technical:

• Add travis
• Add coveragerc
• Update Readme to RST
• Switch setup for automation
• Add basic zpl2 init tests

[lasley]

I'm just assuming?

[lasley]

If you want PyPi, just do this and reply with the secure token so I can add.

travis encrypt 'PYPI_PASSWORD="PYPI PASSWORD"' -r syleam/python-zpl2

Note that if you're trying to maintain a defined release cycle or something, there's better tools (tox). This is just a pretty simple whatever is on master is a production type deal.

[lasley]

If you want Github docs, just do this and reply with the secure token so I can add:

travis encrypt 'GH_TOKEN="GITHUB TOKEN"' -r syleam/python-zpl2

The Github token would be made in Github account settings, and will need write access to this repo.

You'll also need to make a gh-pages branch & clear it out like so - https://help.github.com/articles/creating-project-pages-using-the-command-line/

The bot will handle the rest, as you can see here. I recommend using a bot user instead of your own.

[lasley]

@sylvain-garancher any thoughts on this?

[Garamotte]

Hello @lasley
Thanks for that, this is interresting indeed :)

I developped the lib within the printer_zpl2 Odoo module (which is now merged in the OCA repo), so I made the unit tests in this module. I agree that it would be a good idea to move the tests with the lib.
With the Odoo module's test, the lib is already 100% tested when using coverage run --branch.

I din't have time to write docs, etc. (very busy at the moment), but this is required, obviously.
My PyPI login is alnsgara, but I prefer to push new versions manually.

For the .coveragerc and .gitignore, I usually make them as minimal as possible. I don't like adding extra lines that might be useful some day.

[lasley]

I din't have time to write docs, etc. (very busy at the moment), but this is required, obviously.

Alright sweet I just left this part commented at the moment in the Travis file then. Once we get there, we can uncomment and create the gh-pages. I can alternatively remove if you'd prefer.

My PyPI login is alnsgara, but I prefer to push new versions manually.

Removed PyPi section

For the .coveragerc

Totally agree - I actually meant to curate this for the project and completely forgot. Done

and .gitignore, I usually make them as minimal as possible

I disagree in this case. The reasoning behind a gitignore is so that any contributor can hop in and start working in your repo with ease. What works in one minimal gitignore for you may not for someone else. We've found that this one is fairly inclusive to most development environments, without accidentally excluding the wrong things (except when Javascript starts coming into play).

I'll obviously remove it if you prefer, but I just wanted to state my reasoning before that 😉

[Garamotte]

I disagree in this case. The reasoning behind a gitignore is so that any contributor can hop in and start working in your repo with ease. What works in one minimal gitignore for you may not for someone else. We've found that this one is fairly inclusive to most development environments, without accidentally excluding the wrong things (except when Javascript starts coming into play).

IMO, you shouldn't mix the project's configuration and the development environment's configuration.
A contributor can use the tools he want, create the files he want when working on the project, and should configure his environment for his needs. The project shouldn't assume that maybe, someone will create a file named foobar, so that we ignore this file.

In short:

• The project's .gitignore should only exclude files that are generated by the project itself (*.pyc, .coverage, etc. for example).
• The development environment's (~/.config/git/ignore by default) should exclude files generated/needed by very tools used by the developer.

Some of my colleagues have a .vscode file, I have .ctags, and we don't add these files in the .gitignore of all projects because this is not related to the project.