Closed NimmiW closed 7 years ago
it would be useful, especially if you would be able to do the github integration and run test before merge :)
check with @oliversauter , there's already a plan for CI
@danrl is taking lead on mentoring this as a GSoC project. Here is the Gitbook we use to document our testing efforts: https://www.gitbook.com/book/worldbrain/project-ideas-continous-integration-pipeline/details
TravisCI integration sounds nice, but what tests do you like to run? It's the lack of tests that we have to tackle first.
Even one test would be good, or just compile it. They are 2 problems and it's good to address both.
I have little experience with CI, and I may yet have to understand the current relevance of it for this project, but I would be happy to help set things up if any of you want to take the lead.
My first question is: what exactly would we want to achieve here? The ability to check if your PR breaks things when merged? Making the health of PRs/branches visible to everyone?
My thoughts on this, feel free to correct me:
make test
. Quick checks, or at least the linter, could perhaps be integrated into make watch
.My first question is: what exactly would we want to achieve here?
As the code base gets bigger and bigger and more new code is getting pushed into the repo, we want to make sure we always have backward compatibility(none of the existing code breaks on adding the new code). According to me we should try and setup basic tests for all the main features of the extension and also make tests for the front end so as to make a more stable and clean code base.
Without any checks to run CI seems a bit precipitous.
True. But this is what we are trying to tackle right now. We are trying to build a testing framework along with the CI integration so as to test the code.
Before having written tests, a good first check to run would be a linter
I have opened a discussion for this exact topic on the gitbook of the CI pipeline. Link Please comment and and share your views.
I would prefer to employ a service that could be self-hosted if desired, rather than buying into a single provider. Some questions: Are there more Travis-compatible services? Is it feasible to self-host it? (some answers may be here or here) Would Jenkins/Jervis be friendlier in this regard? What else is there?
Yes there it is feasible to self host it. but considering the size of the project right now and the amount of tests we are looking at, I would not advice it. Since the project is primarily going to be hosted on github for the forseable future, Jenkins(Jervis) would just be an overkill with Travis CI providing most of the features we will struggle to set up on our own server. Although the tests run faster on Jenkins but considering the amount of tests we are looking at it won't make that much difference. There are many other CI frameworks out there that help OS projects like ours but Travis CI is the most user friendly and easiest to setup and quite frankly the most powerful(after Jenkins).
Are there more Travis-compatible services?
I don't understand what service are we looking for. Travis CI comes with Slack and email Integration(sends mail and message once the build the successfull). Sorry if I misunderstood any of the questions. These are just opinions(not facts) I have formed while using Jenkins and Travis CI, please feel free to counter them. For further info
I agree with @reficul31 on all points. About the linter, I don't think it has anything to do with this. Linting, in my experience, only slows down people and never catches real code issue (architecture, complexity, etc). I would, on the other hand, adopt an autolinter for trivial things like tabs/spaces etc.
I think semaphoreCI is also a good choice.
What about drone.io? It's very easy to setup and self host (I'm also a big fan of that). I'm running it for 1+ year now (since I also run my own github web clone gitea). It's as simple as filling in some Github API secrets in a docker compose file, see the installation guide.
@bwbroersma: Thanks for the Drone tip. It looks like it requires a couple of extra steps though, so I opted for trying Travis for now, as I am not even convinced yet of the added value of these build&test services. Moving this project to a self-hosted gitea deployment is a likely future option by the way.
Travis config added in f317827, closing this issue.
This is a suggestion.
If we can implement a continuous integration for webmemex, I think it would be beneficial for the developers.
Any comments or thoughts about that?
Since I am new to open source, your thoughts help me to improve me :)