Discussion: Ideas from the new guy

[7oi]

So hi y'all.

As I'm supposed to be taking care of things getting done 'round here I have a few ideas to make the dev flow neater that I'd like to take to discussion.

1. CI

In my opinion a continuos integration system is essential for a better dev flow. There are multiple options out there, either self-hosted or cloud based like:

• Travis (cloud based, free for open source)
• Jenkins (self-hosted, free)
• Gitlab CI (cloud based, depends on using gitlab.com as the main git server, free for open source)

  2. Dev server

  I think it would be really beneficial to have a dev server. I've read somewhere here that someone feels it's too much hassle to maintain, but if we have CI up and running it would automatically update the dev server on successful builds, so little to no maintenance would be required after setting the dev server up. It's just a valuable tool for testing and have others test, being able to fill it with useless garbage and try to break it without serious consequences. Sure, devs can do that locally, but what about the other users?

3. GitLab

Related to point nr. 1. I think moving projects to Gitlab would be beneficial, since they offer a built-in CI system which would help us. It's really not that much different altogether (apart from pull requests being named merge requests :man_shrugging:) and importing projects from Github is even too simple and imports issues and everything along with it. Notable pros/cons:

• Pros
  • CI built in
  • Unlimited public/private repos
  • Moving is easy
  • Users can link and log in with their Github accounts
  • Nice issue tracker (although Github has a fine one too)
  • Repos should be able to keep in sync between Gitlab and Github (it's an advertised feature)
  • They recently nuked their database by mistake, so they definitely reviewed their disaster recovery strategy recently
• Cons
  • Actually needs moving (even though it only takes minutes).
  • Devs would need to update their upstream or clone again
  • Everyone seems to be on Github
  • Pull requests are called merge requests

Full comparison can be found here https://about.gitlab.com/comparison/

Some other stuff

Since I'm new I'd appreciate some input into prioritization of issues etc. I'll probably be going through everything, commenting, asking questions, arguing about use of spaces vs tabs (my view: pick one and stick with it throughout the whole project. There, that argument settled before it began) and so on .

Also, I would tag every contributor to the project (like GitLab allows you to do, so another point goes to Gitlab), but GitHub only allows tagging individuals, so feel free to tag away in the comments.

So feel free to hack these ideas apart or say amen to them or hang around in the middle of the two.

[7oi]

So, since there's nothing to lose from copying everything to Gitlab I just did it. I created a Píratar group (https://gitlab.com/piratar) and imported wasa2il and icepirate. They also poll the Github repos every hour for changes, so they're nicely mirrored.

Technically we could just keep using Github as is while just utilizing Gitlab for the CI, although the feedback from the CI would never be instant. I encourage all of you to check it out on Gitlab and join the group there.

[7oi]

So, an update on this:

As a proof of concept I have done all the things I mentioned.

wasa2il is now on gitlab.

It has a pipeline up and running that:

• builds the project and runs all the tests (all 0 of them) when new changes are pushed to any branch
  • if build/tests fail, merging the violating branch will not be possible, so breaking the development branch is not an option
• deploys to the staging instance on Heroku when new merge requests are merged into the development branch
• builds a docker container when new tags are pushed and publishes it to the docker registry on gitlab

All this runs automatically and needs little to no maintenance.

The staging server just hangs there, waiting to be messed around with (and I encourage people to try their best to fuck it up). If you need a user let me know. I have no reservations about giving enyone superuser privileges, as the staging environment will never have any sensitive data on it and is meant to be completely expendable. It still has it's own persistent postgres db running so users and data will hang in there between updates, so don't necessarily go around messing up for other superusers.

Apart from minor inconveniences devs may experience with moving to Gitlab, I just see no reason to not do it, especially since it can still be alive and well on GitHub if I set it up so pushes to Gitlab will also push to GitHub (Gitlab is already polling GitHub every hour for changes there).

The next steps I see is actually setting up some tests, possibly start linting the code (flake8, csslint, jslint and the lot) and publishing the reports for test coverage and linting violations to the Gitlab pages (which will also be completely automatic, of course) for easy reference.

So... Again... Thoughts? Anyone?

[viktorsmari]

I love it :)

1. Add the staging server heroku URL to the README, and how it works, something like:

   1. Some developer adds pull(merge) request
   2. PR merged into development branch
   3. Changes should be visible on staging server on heroku

2. In readme, add the URL to Gitlab project.

Also, for people not familiar with Gitlab, it has a 'trello like' board, see: https://gitlab.com/piratar/wasa2il/boards

[7oi]

README updated! Also synced Gitlab -> Github.

[BjarniRunar]

I agree with 1. and 2. but I think 3. is a bad move.

You've already pointed out why: "Everyone seems to be on Github"

Like most OSS projects, this project's biggest problem is getting people to contribute - anything which reduces visibility and hinders participation is bad. So I think moving to Gitlab would be a mistake and I recommend against it.

Edit: Also, welcome! Great to see someone working on this again. :+1:

[7oi]

Well, going to Gitlab doesn't actually mean that we need to remove the project from Github, as I pointed out before. In fact they're syncronized automatically. It will always stay alive and up to date on Github, even though I myself focus mostly on developing on Gitlab.

Besides, everything is open on Gitlab. Anyone can participate there and creating an account is as simple as logging in with Github. Gitlab just offers more feedback with the pipelines and such (which are also open for everyone to look at). For example I'm currently working on publishing coverage and lint reports with every build to Gitlab pages. Of course I will link to them from the README, so they'll be accessible everywhere.

...and thanks! Glad to be here. :)

[BjarniRunar]

I still worry about the dilution of effort; if both Gitlab and Github are in use, how do new contributors know which to use? Where do they file issues? People on one side of the fence will get notifications for a subset of conversations, people on the other side will get another subset. What happens if the next admin likes some other third platform? Do we just keep adding new platforms, hoping they'll magically all stay in sync (yes, I am pessimistic about this)? How much time to we spend worrying about these tools instead of developing code?

It just strikes me as confusing - but since I'm just pontificating from the sidelines I strongly encourage you to use whatever you feel will make you the most productive. The people doing the work get to call the shots!

[helgihg]

I agree with @BjarniRunar on both counts regarding the GitHug/GitLab thing. I'd recommend against it, but you call the shots now. :)

[7oi]

Well, the main reason for using gitlab is of course the extra features. I highly recommend you check the project out over there. Not only do they make development easier in the sense of providing more automatic feedback from tests/linting/building/etc ( I'm still working on improving those factors for wasa2il), but they also protect our main brances from receiving changes that break stuff and make peer review a necessity to be able to merge branches (all optional features that I've enabled). I just feel the advantages outweigh the disadvantages.

Besides, I have no issues with monitoring the issue trackers on both gitlab and github, at least for a while. Plus, updating the readme and wiki to point clearly at gitlab might help.

Besides, the projects haven't actually been flooded with new contributions lately. Not sure if that steady flow will be affected at all..

All that being said, why hasn't anyone started GitHug: the friendliest git?

[bjornlevi]

GITHUG!!

On Jun 14, 2017 17:48, "Jói Fr." notifications@github.com wrote:

Well, the main reason for using gitlab is of course the extra features. I highly recommend you check the project out over there. Not only do they make development easier in the sense of providing more automatic feedback from tests/linting/building/etc ( I'm still working on improving those factors for wasa2il), but they also protect our main brances from receiving changes that break stuff and make peer review a necessity to be able to merge branches (all optional features that I've enabled). I just feel the advantages outweigh the disadvantages.

Besides, I have no issues with monitoring the issue trackers on both gitlab and github, at least for a while. Plus, updating the readme and wiki to point clearly at gitlab might help.

Besides, the projects haven't actually been flooded with new contributions lately. Not sure if that steady flow will be affected at all..

All that being said, why hasn't anyone started GitHug: the friendliest git?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/piratar/wasa2il/issues/153#issuecomment-308507666, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvcMK8anEnn8AK8UIJi9ckzzECDMsSIks5sEBz7gaJpZM4Ny37g .

[nifgraup]

I've recently started to use the Watch feature at GitHub where I follow a small set of projects. It would be nice if wasa2il doesn't drop out of that list.

[7oi]

It won't drop out. I think it would be insensible to retire the project from Github. I will make sure that any updates on either place will be mirrored on both.

In fact, you might call it a GitHug...

I just feel that gitlab has the right tools for the development process. Sure, I am definitely biased as I use gitlab at work (although not to the level I'm aiming for here), and I could probably find some tools that integrate nicely with Github that can achieve similar results, but as it is I've gotten a continuous integration pipeline running in a good amount of time that runs tests, lints the code nd published coverage reports (almost done with that), builds a docker container and releases it in to gitlabs docker registry for easy access via docker, and auto deploys the current state of the development branch to a staging environment on Heroku, all just using gitlabs native capabilities.

I still encourage all of you to take a look at it. Log into gitlab (you can do so with your Github account, actually), join the Píratar group and just pick at it. If you don't like it, come back here. It'll still be here, up to date and also benefitting partly from the work being done on Gitlab.

GitHugs around!

[7oi]

So, I believe an update is in order.

I'm having a change of heart. I got to browsing through the Github marketplace and found and excellent tool for linting and code coverage reports called Codacy. So I took a peek at Travis again, after having last used it about 5 years ago, and voila. The exact thing I was working to achieve was doable with this pipeline.

Therefor I have a feeling that Gitlab has been rendered unnecessary.