Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving Away from Travis CI

ropensci.org

Post reply on HN
Print view View original

31–40 of 79 posts

Re: Moving Away from Travis CI

#31

Post by tcbasche »

jniedrauer wrote: post #16
tcbasche wrote: post #9

Earlier quoted context omitted.

I have had good experiences with Concourse CI, especially for trunk-based development

How do you host concourse? Did you adopt their entire stack? Last time I looked at it, it seemed cool but I had no interest in learning BOSH.

It all runs on a couple of ec2 instances in AWS. I'm not the guy who installed it (and I started at my current company after it was setup so maybe it was complicated?) but as far as maintenance goes it's been pretty much set and forget. Our team is pretty DevOps heavy and we never really need to do anything with it.

Definitely easier though than using something like Jenkins, but personally I'm a big fan of Github Actions. I've never used it in a production setting though, only for personal projects.

Re: Moving Away from Travis CI

#33

Post by Rmblnm4n »

mschuster91 wrote: post #22
jniedrauer wrote: post #17

Earlier quoted context omitted.

Chiming in to say: Avoid Jenkins like the plague. Jenkins is a bottomless pit of vulnerabilities and obscure bugs and outdated documentation that will waste weeks of your life. (Caveat: If you plan to do devops at a Big Corp, then you might as well get good at Jenkins because they already use it.)

Gitlab CI could almost replace Jenkins. I say almost because Gitlab CI lacks one critical thing: support for tasks independent of a commit or other event. Stuff like "take a dump of the production database and synchronize it to the integration environment". Also, Gitlab CI is, due to its nature of polling workers instead of the master pushing work to the slave as well as spinning up a new container for each job inste…

In-house micro services could solve this.

Then SRE is eating the Kube dog food.

Semantic games are the only reason there’s a gap between dev and SRE work anymore.

It’s all HTTP/RESTY APIs with ACLs on who can GET versus GET+PUT

Snapshot state to DocumentDB and rerun it through AWS SDK based services.

The cloud ops world has gone utterly bonkers with tool sprawl.

Re: Moving Away from Travis CI

#34

Post by hinkley »

geerlingguy wrote: post #15

I wrote a blog post about this a couple weeks ago [1], and I think as a result of writing it in the midst of the week-long annoyance that I had at having to quickly move my active projects over to GH Actions, I may have been a bit too negative in my overall tone. I do like that this post expresses the gratitude for many years of free OSS CI that Travis did provide, and I especially want to echo that and thank the ori…

I think in general we are tuned to have a stronger reaction to unexpected setbacks. The people who have no aversion to them end up dying by a thousand cuts, as a long series of predictable but ignored scenarios play out one after another. In the most delusional cases, blaming it all on bad luck instead of lack of foresight.

Not every setback is a pattern, but if you have no histamine response at all then you will miss a lot of preventable issues.

Re: Moving Away from Travis CI

#35

Post by jacques_chester »

jniedrauer wrote: post #16
tcbasche wrote: post #9

Earlier quoted context omitted.

I have had good experiences with Concourse CI, especially for trunk-based development

How do you host concourse? Did you adopt their entire stack? Last time I looked at it, it seemed cool but I had no interest in learning BOSH.

Kubernetes deployments overtook BOSH deployments in the last Concourse community survey: https://blog.concourse-ci.org/community-survey-2020-results/...

I suspect that support for the BOSH deployment will eventually be discontinued.

Disclosure: I work for VMware, which sponsors Concourse. My own views.

Re: Moving Away from Travis CI

#36

Post by jacques_chester »

joseph wrote: post #30
jniedrauer wrote: post #16

Earlier quoted context omitted.

How do you host concourse? Did you adopt their entire stack? Last time I looked at it, it seemed cool but I had no interest in learning BOSH.

I also love Concourse and feel it has the perfect set of abstractions to be able to compose arbitrarily complex pipelines. You can extend it by creating your own resources (I actually wrote a tool to help make this easier[0]). The pipeline visualization is better than anything else I've seen. I'm not aware of a hosted Concourse solution, but there really should be. BOSH is not a requirement to host it yourself, and I…

> I'm not aware of a hosted Concourse solution, but there really should be.

Yes, there should. If you're a VC and that interests you, I've got so many slides.

Re: Moving Away from Travis CI

#37

Post by 0x1F8B »

What I would do is find a way to decouple your test running system from the lifecycle tooling. Develop a custom solution that run CI pipelines in k8s and collates results and passes them upstream to the lifecycle tooling whether it's GitHub Actions or Jenkins or whatever. By doing this you free your pipelines from lock-in and can utilize cheap compute (DigitalOcean, GKE pre-emptibles, etc).

Take a look at Tekton CI/CD for a good primitive that you can build on.

Re: Moving Away from Travis CI

#38

Post by toomanybeersies »

0x1F8B wrote: post #37

What I would do is find a way to decouple your test running system from the lifecycle tooling. Develop a custom solution that run CI pipelines in k8s and collates results and passes them upstream to the lifecycle tooling whether it's GitHub Actions or Jenkins or whatever. By doing this you free your pipelines from lock-in and can utilize cheap compute (DigitalOcean, GKE pre-emptibles, etc). Take a look at Tekton CI/C…

Buildkite is BYO infrastructure. It's worked really well for us, as we have a fairly idiosyncratic build process/test suite that out of the box solutions like GH Actions or CircleCI don't really cater to.

Re: Moving Away from Travis CI

#39

Post by MaulingMonkey »

0x1F8B wrote: post #37

What I would do is find a way to decouple your test running system from the lifecycle tooling. Develop a custom solution that run CI pipelines in k8s and collates results and passes them upstream to the lifecycle tooling whether it's GitHub Actions or Jenkins or whatever. By doing this you free your pipelines from lock-in and can utilize cheap compute (DigitalOcean, GKE pre-emptibles, etc). Take a look at Tekton CI/C…

Just having your CI steps run scripts that install/build/deploy/??? already goes a long way to decoupling from your CI solution, and can be a lot faster than spinning up a custom image for your CI build. Custom images don't necessairly do much for fixing the last 10% either - I'll typically want CI-specific:

1. Build matricies. I was running windows builds on appveyor and linux builds on travis for a long time (faster builds / iteration / feedback.) Regression testing against multiple rustc versions can be done from within a script, but doing so via CI-configuration makes for easier to read CI results that flag individual builds as failed instead of an entire script that you have to go log diving into.

2. Custom runners. Be it custom hardware or licensing-burdened custom software, I frequently need to own the actual CI hardware, and using the native solutions for CI runners is typically easier than merely configuring whatever custom infrastructure I might come up with.

3. Images. Using prewarmed cloud-ci-specific images is often faster to spin up.

Re: Moving Away from Travis CI

#40

Post by cube00 »

> The native integration with GitHub this takes away the annoying authentication dance that is required for third party services.

We really need to improve the "annoying authentication" so this doesn't become a reason to continue building silos with a single vendor.

Post reply on HN