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

51–60 of 79 posts

Re: Moving Away from Travis CI

#51

Post by nemo1618 »

koeng wrote: post #2

Any recommendations on good open source CI / CDs? Right now I just use github actions, but am interested in other self hosted options.

I know this isn't super helpful, but I built my own bors-style CI bot over a few weekends, and I'm very satisfied with it. It looks for PR comments with a specific keyword, then pulls the branch, tests it, and pushes a merge commit automatically.

Taking this approach has two big upsides. First, the bot is just a binary running on a cheap VPS; so I know that it'll be fast and that I can ssh in at any time to debug if necessary. Second, if there's a feature that I want, I can just add it, rather than twiddling my thumbs. For example, I noticed that I was manually deleting my merged PR branches every time, so I added a few lines to the bot and now it deletes them automatically.

The obvious downsides of this approach are: 1) Implementing even an MVP of such a bot can consume significant time and energy, which you may not have a lot of; 2) If there's a bug, it's your fault and now you need to spend more time and energy tracking it down; and 3) Your bot might have a security vulnerability that exposes secrets, allows injection attacks, etc.

I'd love to see tooling/frameworks that make it easier to create custom CI systems. I think startups (and perhaps larger companies as well) could benefit a lot from building a CI in-house, since it allows you to optimize for your own specific needs. I see a lot of parallels to code linters, where spending a bit of time writing custom lint rules or static analysis tools can have a large payoff.

Re: Moving Away from Travis CI

#52

Post by systematical »

I am/was using Travis for my open source projects. I started noticing my builds taking forever. I did some checking around and decided its just easier to move to github actions rather than figuring things out.

It will be a slow but easy migration.

Re: Moving Away from Travis CI

#53

Post by xvilka »

jniedrauer wrote: post #14

I'm surprised people are still using Travis CI. The writing was on the wall the day of the acquisition. I moved all of my builds immediately.

We (radareorg/radare2 team) use Travis CI specifically to build and run tests on ARM64 (ARMv8 or AArch64), PowerPC64, and SystemZ (s390)[1]. No other CI service offers those. I wish there were also MIPS, SPARC, and RISC-V.

[1] https://travis-ci.com/github/radareorg/radare2/builds/202966...

Re: Moving Away from Travis CI

#54

Post by TylerE »

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…

Couldn't you do something like have a dummy repo just for trigger things, and then make commits to it via cron?

Re: Moving Away from Travis CI

#55

Post by shakna »

xvilka wrote: post #53
jniedrauer wrote: post #14

I'm surprised people are still using Travis CI. The writing was on the wall the day of the acquisition. I moved all of my builds immediately.

We (radareorg/radare2 team) use Travis CI specifically to build and run tests on ARM64 (ARMv8 or AArch64), PowerPC64, and SystemZ (s390)[1]. No other CI service offers those. I wish there were also MIPS, SPARC, and RISC-V. [1] https://travis-ci.com/github/radareorg/radare2/builds/202966...

sr.ht supports ARM64, PowerPC, and SystemZ from what I can see on the list of supported builds: [0]

They also support MIPS (and their BSD builds support SPARC).

[0] https://man.sr.ht/builds.sr.ht/compatibility.md

Re: Moving Away from Travis CI

#56

Post by cghendrix »

hinkley wrote: post #46
Waterluvian wrote: post #5

Earlier quoted context omitted.

Jenkins is powerful and painfully complex. You might need that complexity for large projects but personally I've found it to be so frustrating to set up simple stuff.

As we discussed in a previous thread, the features tend to become a trap of lock-in. Often better to have your scripts do most of the work and the build tool handle triggers, bookkeeping, and some statistics.

That does seem like the best practice.

Re: Moving Away from Travis CI

#57

Post by digi59404 »

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…

Hey op - Wanted to chime in here some of the things you said aren’t accurate anymore.

GitLab CI has the ability to do SSH on the Runners. You deploy a runner and configure it to use SSH. Then it won’t use containers at all and instead use SSH.

The same is true for configuring the runner in a shell capacity. You can then reuse the same environments over and over just like Jenkins does.

As for Maven and NodeJS if you’re using containers, you simply build a dockerimage with those baked in, and use it for your builds. GitLab also has container storage that allows your images to work seem less and quickly with the runners.

For independent tasks without commits. You can easily configure a gitlab job to trigger only if a pipeline variable is present. Then trigger the pipeline via HTTP POST Request, via the UI or vi an event.

I talk about and demonstrate all of these topics on my blog www.lackastack.com - Shameless plug, but I hope it helps.

Re: Moving Away from Travis CI

#58

Post by theptip »

tcbasche wrote: post #9
koeng wrote: post #2

Any recommendations on good open source CI / CDs? Right now I just use github actions, but am interested in other self hosted options.

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

I really liked the expressivity of the yaml syntax when I did some prototyping with Concourse recently, and the Resource abstraction is very nice.

I found the docs to be thorough for the API, and really sparse for how to actually wire up a GitHub build pipeline or do a deploy to k8s, seems it’s really niche and not many people are writing guides, which concerns me.

Re: Moving Away from Travis CI

#59

Post by xvilka »

shakna wrote: post #55
xvilka wrote: post #53

Earlier quoted context omitted.

We (radareorg/radare2 team) use Travis CI specifically to build and run tests on ARM64 (ARMv8 or AArch64), PowerPC64, and SystemZ (s390)[1]. No other CI service offers those. I wish there were also MIPS, SPARC, and RISC-V. [1] https://travis-ci.com/github/radareorg/radare2/builds/202966...

sr.ht supports ARM64, PowerPC, and SystemZ from what I can see on the list of supported builds: [0] They also support MIPS (and their BSD builds support SPARC). [0] https://man.sr.ht/builds.sr.ht/compatibility.md

There are no checks in those - they are empty fields.
Post reply on HN