Create a CI pipeline about rdiff-backup

[ericzolf]

Few comments from me:

• yes we need CI/CD!
• Flake8/PEP8 - yes, please! (the current tabs are ugly and killing my editor) - my next task after Python3 is merged would be to fix all files in this regard.
• regarding the current tox setup - my impression is that many things are tested multiple times which cost time, we might want to clean this to optimize waiting time at merge time but can be a 2nd step
• it would be nice to have a test coverage measurement tool (I think it's not too bad, but actually no clue)

[ottok]

Yes, code coverage is a good idea and it should be possible to have with Tox (see e.g. https://www.rfk.id.au/blog/entry/testing-better-coverage-tox/).

I have now activated https://travis-ci.org/rdiff-backup/rdiff-backup but there is no real .travis.yml file done yet.

[ottok]

First PR filed as #96

[ottok]

Second step will be running full Tox suite. WIP at https://github.com/rdiff-backup/rdiff-backup/tree/feature/travis-ci-tox

[ottok]

I have been playing around with different approaches to Travis-CI at https://travis-ci.org/rdiff-backup/rdiff-backup/builds using just one big job, or a matrix, or stages. I am not sure what route to take here. Does anybody have comments? @ikus060 maybe?

[ikus060]

@otto I'm on mobile, a bit harder to point you to the right direction. For rdiffbackup will need to compile with manylinux. https://github.com/pypa/manylinux Take a look a their example projet. We need to compile with manylinux since we have extension in c.

…

On Sun, Sep 1, 2019, 3:26 AM Otto Kekäläinen, ***@***.***> wrote: I have been playing around with different approaches to Travis-CI at https://travis-ci.org/rdiff-backup/rdiff-backup/builds using just one big job, or a matrix, or stages. I am not sure what route to take here. Does anybody have comments? @ikus060 <https://github.com/ikus060> maybe? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48?email_source=notifications&email_token=AAHA5I5XYPGAZYYOC3GDHGLQHNVDJA5CNFSM4IKGZMFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5T4LDY#issuecomment-526894479>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHA5I2NB5KI3C7HCJXJUDLQHNVDJANCNFSM4IKGZMFA> .

[ottok]

I think I will settle with this "user experience":

[ericzolf]

The steps look good to me, without exactly knowing what is behind each of them. Are you able to test each Python version from 3.5 till 3.8?

[ottok]

You can see it at https://travis-ci.org/rdiff-backup/rdiff-backup/builds and followg the links to the commits or view the whole WIP branch at https://github.com/rdiff-backup/rdiff-backup/tree/feature/travis-ci-tox

ATM the goal is just to get the tests pass so we can prevent new regressions from sneaking in, and then we can start to expand the tests, the Python versions and the platforms later on.

[ikus060]

Could we close this ticket ? Looking at the current Travis pipeline everything is good to me. If anything is missing we should probably create a separate tickets that are more specific.

[ericzolf]

I think we should first add at least all relevant versions of Python (3.5 to 3.8) before we do this. It's a small thing, adding other platforms and the automated generation of binaries would need to go into another issue. What do you think?

[ikus060]

ok, I will start working on travis build to add other version. But seriously, if it's not working for 3.5 or 3.6, I'm fine to only support py3.7.

1. adding other platforms see #105 should cover Windows
2. automated generation of binaries, just created #188