Move to GitLab CI/CD instead of Travis?

[vprithvi]

From Gitlab's docs, they support GitHub integration, and "gives open source projects hundreds of concurrent jobs with 50,000 free CI pipeline minutes".

In light of the news around TravisCI, I think we should evaluate alternatives.

[jpkrohling]

Yes, please! I'm a huge fan of GitLab CI, especially for its ability to run "workers" (gitlab-runner) on our own laptops. I believe this would also make it easier to run e2e tests with workers within VPNs, with the results being visible/available to the community.

Suggestion: we could first move to GitLab CI for the Operator repository and see how it goes, as it has similar requirements as the main repo, but if it breaks, it's not as problematic as this one here.

cc @kevinearls

[yurishkuro]

What happens after "free N minutes" are exhausted?

[jpkrohling]

OpenSource projects get the Gold plan for free, which includes 50,000 CI pipeline minutes in their shared runners. If we use it up, we can have private runners inside a machine of "ours". I'm sure we would find a place for the runners if we ever reach this number :-)

Is it possible to get a report from Travis with the average amount of minutes per month we used in the last year?

[caniszczyk]

CNCF is happy to establish a relationship with GitLab to ensure that you have enough minutes, just let me know how much you'll need roughly

…

On Fri, Feb 22, 2019 at 8:45 AM Juraci Paixão Kröhling < ***@***.***> wrote: OpenSource projects get the Gold plan for free, which includes 50,000 CI pipeline minutes. If we use it up, we can have custom runners inside a machine of "ours". I'm sure we would find a place for the runners if we ever reach this number :-) Is it possible to get a report from Travis with the average amount of minutes per month we used in the last year? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1369 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD5IfQRTC38DsuVCJogyL7TVXvBCzS0ks5vQAJygaJpZM4bIAnf> .

-- Cheers, Chris Aniszczyk http://aniszczyk.org +1 512 961 6719

[vprithvi]

This site shows an visualization of build times - we've used roughly 28 hours or 1680 minutes of build so far this month. 50k minutes works out to running a single executor for ~34 days!

[markpundsack]

Anything we can help with? It should be a fairly easy transition, and you can certainly try it out before removing your Travis setup.

[vprithvi]

I just created a MR for Gitlab OSS project status.

@markpundsack Thanks for the offer! We'll ping you if anything comes up!

I think the next steps are to create the build definition files for Gitlab, and set up a CI pipeline. By setting the Gitlab check as optional, we can see how it fares when compared to Travis.

One thing that is much more verbose on Gitlab build scripts are matrix builds (The builds need to use YAML anchors, instead of the nicer definition Travis provides)

[jmichalek132]

any progress on this?

[jpkrohling]

We talked a bit about it during the last bi-weekly meeting. People also mentioned AppVeyor and CircleCI, but we were running short of time and kinda skipped a conclusion.

We are currently using GitHub Workflow in the Jaeger Operator, and I'm quite happy with it, apart from a few annoying bugs (actions/checkout#23, I'm looking at you). To me, that's what we should be using in the future, especially once their private runners becomes real.

[jmichalek132]

So no gitlab than?

[vprithvi]

I'm curious - what specific issues are you running into with the current setup?

[jpkrohling]

No GitLab. I think @kevinearls did some tests with GitLab when we thought about moving off of Travis some months ago for the Jaeger Operator, but decided it was better to stay with Travis for the moment (back then). Perhaps he can add more details, in case you are interested.

[jmichalek132]

I am I don't have that much experience with travis and I am currently writing gitlab pipeline to build jaeger.

[kevinearls]

Sorry for the delay but I was on vacation. The advantage of Travis and GitHub Workflow is that we can start multiple instances of minikube to run e2e tests in parallel, which means we can validate PRs in a reasonable amount of time.

I can't find my notes on this at the moment, but if I remember correctly Gitlab says it has great integration with Kubernetes instances that you own on GCE/GKE, but it doesn't permit you to create short term minikube instances the way GitHub and Travis do.

[yurishkuro]

Interesting bit from Linkerd Community Meeting notes:

Moved CI off of TravisCI on to GitHub Actions. Were hitting lots of issues w/Travis; now things are vastly improved
Thomas PROMISES to [try to convince someone to] write a blog post about how awesome this is

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[pavolloffay]

Closing we are using github actions now.