Closed dvolgyes closed 7 years ago
I'd be broadly in favour of this, but I think it's @natekupp who would have to sign up to the external services (since he owns the Github username). :)
On 26 June 2017 at 15:03, David Volgyes notifications@github.com wrote:
Continuous integration helps to spot build errors, interpreter incompatibilities, etc. Travis CI ( https://travis-ci.org/ ) offers free service for open source projects hosted at Github. After signing up, the result is something like this, if the configuration file has been correctly set up: https://travis-ci.org/dvolgyes/ffx/
Code coverage has a similar purpose: to measure which parts of the code are actually executed. Travis has a good integration with Coveralls.io which offers free code coverage reports for open source projects. Similarly, the outcome is something like this: https://coveralls.io/github/dvolgyes/ffx
This pull request contains a Travis configuration file which executes a basic test (tests/x_square_test.py) and uploads the code coverage report to Coveralls.io
The readme file is updated with the corresponding build and coverage 'badges'.
My recommendation:
- sign up for Travis
- sign up for coveralls.io
- merge the pull request
- check Travis and coveralls for the results (and revert the changes if you are not satisfied)
Later:
- check new pull requests before merge in Travis (they will be tested if you let it)
- try to add new test cases and cover the whole codebase. :)
Travis and Coveralls alternatives:
- Semaphore CI ( https://semaphoreci.com/ )
- codecov ( https://codecov.io/ ) But in my opinion and at this current moment Travis and Coveralls are more mature.
You can view, comment on, or merge this pull request online at:
https://github.com/natekupp/ffx/pull/24 Commit Summary
- Travis CI
- code coverage at coveralls.io
File Changes
- A .travis.yml https://github.com/natekupp/ffx/pull/24/files#diff-0 (41)
- M Readme.md https://github.com/natekupp/ffx/pull/24/files#diff-1 (3)
Patch Links:
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/natekupp/ffx/pull/24, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKQBt1G_N5rwIwFOPB8R1PcOmgW2QKLks5sH7pGgaJpZM4OFW0K .
-- Dr. James McDermott Lecturer in Business Analytics Programme Director, MSc in Business Analytics D209 UCD Michael Smurfit Graduate Business School College of Business, University College Dublin, Ireland. Phone +353 1 716 8031 <+353%201%20716%208031> http://jmmcd.net http://www.ucd.ie/cba/members/jamesmcdermott/
Hi @dvolgyes - first, thanks so much for diving in here! Setting up CI for FFX has been on my wishlist for quite some time, and I just haven't had the time to think about this. Agree with Travis/Coveralls being a good route to go. I'd also love to set up the Github-side to make master a protected branch and require CI to pass before a PR can be merged.
Second, and this is for @jmmcd also - would this be a good point to create an FFX "organization" and set up all of this on the repository there? I'm happy to add both of you as owners and migrate the repository there. That might make more sense towards shared stewardship of this codebase, especially as I step further and further away from coding in my day-to-day work. If not, I'll try to find some time this coming weekend to get to setting up Travis/Coveralls :)
Hi, CI is easier than you think. The github and travis are very well integrated. When you sign up for Travis, it asks for permission for github repository. It is mandatory, it has to install commit hooks. But in the settings you can enable/disable travis for
I would say that the whole process takes around 10 minutes, and I really recommend it because it will change your thinking about your other/future projects. (Regardless who sets up the CI, I recommend everyone else to make a fork, and try to set up a Travis on the fork. It really changes you, and it is much more simple than it sounds. )
Organization: everything is forkable, and you can add the hooks to these forks, just like i did for the my pull request. So I would say that enabling CI is independent from this kind of restructuring. I try to help projects of my interest with pull requests but I am also quite busy. So I definitely would not be a good steward. I will submit my thesis in the winter, so I will disappear for weeks, maybe months. Besides, maintainer can push commits without code review. A pull request would be reviewed which improves the quality in general. So I would argue against large number of maintainers. If @jmmcd can step up as a maintainer, I am happy for him, and if it is needed, I could be maintainer too. But in general, I would not recommend myself because of my time limitations. But regardless of the outcome, whenever I have an idea, then I will make a pull request and share it.
+0 to having an FFX organisation. So far, I haven't been very active, just occasionally fixing a bug or accepting a pull request. I'm happy to continue with that either as-is or in a new FFX organisation.
On 27 June 2017 at 08:46, David Volgyes notifications@github.com wrote:
Hi, CI is easier than you think. The github and travis are very well integrated. When you sign up for Travis, it asks for permission for github repository. It is mandatory, it has to install commit hooks. But in the settings you can enable/disable travis for
- branches
- branches without travis.yaml file
- pull requests As far as I remember, the default is to enable all of them. So when you have a commit, it will be tested. But also you automatically get the option for testing pull requests, branches, merges, etc. Briefly:
- you do not have to do anything with github, you just grant some permissions
- in travis, most of the settings come from the github hosted config file, the user interface is quite minimal. Basically, you have to select which repositories you want to enable.
- coveralls: same like travis: which github repository you want to enable
I would say that the whole process takes around 10 minutes, and I really recommend it because it will change your thinking about your other/future projects. (Regardless who sets up the CI, I recommend everyone else to make a fork, and try to set up a Travis on the fork. It really changes you, and it is much more simple than it sounds. )
Organization: everything is forkable, and you can add the hooks to these forks, just like i did for the my pull request. So I would say that enabling CI is independent from this kind of restructuring. I try to help projects of my interest with pull requests but I am also quite busy. So I definitely would not be a good steward. I will submit my thesis in the winter, so I will disappear for weeks, maybe months. Besides, maintainer can push commits without code review. A pull request would be reviewed which improves the quality in general. So I would argue against large number of maintainers. If @jmmcd https://github.com/jmmcd can step up as a maintainer, I am happy for him, and if it is needed, I could be maintainer too. But in general, I would not recommend myself because of my time limitations. But regardless of the outcome, whenever I have an idea, then I will make a pull request and share it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/natekupp/ffx/pull/24#issuecomment-311280151, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKQBnbTDkXr7Rk9noZiKOvzBQKg5fGMks5sILM6gaJpZM4OFW0K .
-- Dr. James McDermott Lecturer in Business Analytics Programme Director, MSc in Business Analytics D209 UCD Michael Smurfit Graduate Business School College of Business, University College Dublin, Ireland. Phone +353 1 716 8031 http://jmmcd.net http://www.ucd.ie/cba/members/jamesmcdermott/
Cool, thank you both for the feedback. I got a few minutes free this morning and turned on Travis/Coveralls and merged this PR. Looks like everything is working - I'll leave the organization question for now and we can revisit in the future.
Continuous integration helps to spot build errors, interpreter incompatibilities, etc. Travis CI ( https://travis-ci.org/ ) offers free service for open source projects hosted at Github. After signing up, the result is something like this, if the configuration file has been correctly set up: https://travis-ci.org/dvolgyes/ffx/
Code coverage has a similar purpose: to measure which parts of the code are actually executed. Travis has a good integration with Coveralls.io which offers free code coverage reports for open source projects. Similarly, the outcome is something like this: https://coveralls.io/github/dvolgyes/ffx
This pull request contains a Travis configuration file which executes a basic test (tests/x_square_test.py) and uploads the code coverage report to Coveralls.io
The readme file is updated with the corresponding build and coverage 'badges'.
My recommendation:
Later:
Travis and Coveralls alternatives: