Live data from Hacker News

Travis CI's new pricing plan threw a wrench in my open source works

jeffgeerling.com

101–110 of 148 posts

Re: Travis CI's new pricing plan threw a wrench in my open source works

#101
post #8

Hey Jeff, This is hitting me hard, too. I hope this is the right moment for me to pipe up and say this: I always just do the minimum with these CI integrations to get my shell script to run. I am grateful for the free minutes they offer open source projects - but any of the deeper integrations, the advanced automation? No, thanks. It's not like the other developers who use what I write have any more motivation than I…

> I always just do the minimum with these CI integrations to get my shell script to run.

Absolutely. Moving CI systems always shows up where your build logic has leaked into the CI system, rather than staying in your repo.

If you can't identically build your code from the command line and from the CI system, you're going to have problems.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#102
post #99

What kind of monstrous CI process can take 4 weeks to migrate? I know from experience that CI takes a lot of time, but even the very worse one that I have worked so far (dozens of parallel runs on different machines and a thousand lines of yaml) only took me 3 days to migrate.

Have you read the article? The author has literally hundreds of repositories on github.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#103

Earlier quoted context omitted.

Azure Pipelines has been really good for us. Much much more reliable than travis, and decent pricing. For self-hosted, I've heard really good things about build-kite ( https://buildkite.com/ ) although I've not used it myself.

I can’t see where build-kite is self hosted. It seems like you must use their SaaS dashboard which makes it DOA for me.

The build agents are self-hosted. So it would work for the GP where they are open to hosted services but have their own compute that they might want to use.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#104
post #98

Get a cheap server and just self host drone. It’s been rock solid for me. Although I am using GitHub actions more, drone powers all of more heavy duty docker builds.

Drone has recently been bought by Harness. Will it still be around in a year or two?

Re: Travis CI's new pricing plan threw a wrench in my open source works

#105
post #42

I am rooting for the SourceHut CI[1][2][3]. Along with other services it has proven useful even at the current (alpha stage). Also it's the only one that supports both FreeBSD and OpenBSD (NetBSD support is unfinished [4]) [1] https://builds.sr.ht/ [2] https://man.sr.ht/tutorials/getting-started-with-builds.md [3] https://man.sr.ht/builds.sr.ht/compatibility.md [4] https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master…

To plug another CI service, there is https://ci.cppget.org with focus on C/C++. It's free and unlimited for open source projects, including Windows and Mac OS.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#106
post #85
post #80

Earlier quoted context omitted.

Or use a CI/CD tool that natively supports Docker, like Concourse. Added bonus is that pipelines are defined in YAML rather than web GUI so you can version control the pipelines themselves and not just any build or test suites.

Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation). I have heard good things about Concourse, want to give it a try in the future!

I've bounced off concourse several times now. The promise is great, but the setup is absurdly complex and at the end I'm stuck with CI in Docker containers (I usually want 1 or more VMs)

Re: Travis CI's new pricing plan threw a wrench in my open source works

#107
post #18
post #9

I've been using Travis on a bunch of my opensource projects and was wondering why builds were getting queued for ~a day before they'd run, I guess I got my answer. :/ I don't really want to lock myself into GH actions (ideally, I wouldn't be on GH at all), does anyone have any suggestions for alternatives? I don't mind paying some money, but the almost $1K/year for Travis' lowest tier is about an order of magnitude m…

Github Actions really is a freakin awesome product. Yeah, there's lock-in, but their free plan (and cheap Pro plan for individuals) offers a great value. And, really, CI is CI; if you ever need to migrate, even for this guy with hundreds of projects it should only take a couple days. Once you've seen one CI yaml file, you get the gist of what all of them do. Other options: * Gitlab CI. Good value, great integration w…

One thing people forget about GitHub Actions is that you can self-host the runners for unlimited CI minutes (or custom hardware/os combos)! Just like on GitLab CI.

https://docs.github.com/en/free-pro-team@latest/actions/host...

Re: Travis CI's new pricing plan threw a wrench in my open source works

#108
post #106
post #85

Earlier quoted context omitted.

Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation). I have heard good things about Concourse, want to give it a try in the future!

I've bounced off concourse several times now. The promise is great, but the setup is absurdly complex and at the end I'm stuck with CI in Docker containers (I usually want 1 or more VMs)

Concourse can run as many VMs as you want. The point is those jobs get pushed to a farm of workers (typically VMs) and then docker is used so you have an ephemeral and repeatable build environment. It is absurdly complex to set up though. I feel there is a gap in the market for a Concourse-like solution but simplified immensely.

Re: Travis CI's new pricing plan threw a wrench in my open source works

#109
post #8

Hey Jeff, This is hitting me hard, too. I hope this is the right moment for me to pipe up and say this: I always just do the minimum with these CI integrations to get my shell script to run. I am grateful for the free minutes they offer open source projects - but any of the deeper integrations, the advanced automation? No, thanks. It's not like the other developers who use what I write have any more motivation than I…

You want coworkers and collaborators to have such an easy time validating build failures locally that only an idiot or an asshole won’t do anything about a problem they may have caused.

Developers hate being thought of as idiots, and being an asshole is a problem you can take to HR. So for the people who don’t pitch in on general principle, straightforward processes help bring them around. And in general that means not leaning on clever CI features, and instead leaning hard on the CLI tools your ecosystem supports.

There are exceptions to every rule of course. Features around scheduling have little to no impact on what gets built and how, just when and why. Similarly, analytics have second order effects on how and when, but once a problem is discovered you can mostly ignore them for a while. Integration with external tools and services on the other hand, should always be questioned. Do I have another way to do this mostly outside of the CI system?

Re: Travis CI's new pricing plan threw a wrench in my open source works

#110
post #8

Hey Jeff, This is hitting me hard, too. I hope this is the right moment for me to pipe up and say this: I always just do the minimum with these CI integrations to get my shell script to run. I am grateful for the free minutes they offer open source projects - but any of the deeper integrations, the advanced automation? No, thanks. It's not like the other developers who use what I write have any more motivation than I…

My .travis.yml for a node project is pretty simple: https://github.com/serprex/openEtG/blob/542c645c53dba36d6653...

Python's easy too: https://github.com/serprex/aespython/blob/c3256b656308af8119...

A Rust repo I contribute to has a .travis.yml not created by me, but still pretty simple: https://github.com/dpc/hex2d-rs/blob/master/.travis.yml

edit: updated node project to Github Actions https://github.com/serprex/openEtG/commit/4196992bb23ce43f34...

Post reply on HN