WebMemex / webmemex-extension

📇 Your digital memory extension, as a browser extension
https://webmemex.org
Other
208 stars 45 forks source link

Suggestion: Travis CI integration #71

Closed NimmiW closed 7 years ago

NimmiW commented 7 years ago

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 :)

obsidianart commented 7 years ago

it would be useful, especially if you would be able to do the github integration and run test before merge :)

obsidianart commented 7 years ago

check with @oliversauter , there's already a plan for CI

blackforestboi commented 7 years ago

@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

danrl commented 7 years ago

TravisCI integration sounds nice, but what tests do you like to run? It's the lack of tests that we have to tackle first.

obsidianart commented 7 years ago

Even one test would be good, or just compile it. They are 2 problems and it's good to address both.

Treora commented 7 years ago

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:

reficul31 commented 7 years ago

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

obsidianart commented 7 years ago

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.

Chaitya62 commented 7 years ago

I think semaphoreCI is also a good choice.

bwbroersma commented 7 years ago

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.

Treora commented 7 years ago

@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.