Daniel Stenberg: curl doesn't qualify for TravisCI free tier | Hacker News Reader

Daniel Stenberg: curl doesn't qualify for TravisCI free tier

twitter.com

66 pointsyawaramin34 comments

I'm somewhat surprised, given that hosting cURL used to be their primary selling point for their OSS offering[citation needed].

But, they haven't replied to my support emails in ~6 months.

For context: Travis announced a migration from travis-ci.org to travis-ci.com[0] and gradually cut off resources from travis-ci.org to encourage people to migrate[1].

Without notice, they changed the pricing scheme (both for free and paid customers) to a level which effectively meant all OSS projects would have to pay significant amounts of money[2], migrate, or request credits on a monthly basis. The terms for registering as a FOSS project excluded a significant amount of projects, and despite offering a free tier, I didn't know of a developer which this was granted for (until now).

I don't expect that Travis hosts any major OSS projects at this point.

[0] https://docs.travis-ci.com/user/migrate/open-source-reposito...

[1] https://travis-ci.community/t/build-delays-for-open-source-p...

[2] https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing

Choice quote while trying to find a citation:

> Testing your open source projects will always be free!

> Seriously. Always. We like to think of it as our way of giving back to a community that connects so many people.

https://web.archive.org/web/20200229150620if_/https://travis...

"testing"

Any free service held up by fundraising will eventually run out of money and end that service. People forget the dozens of photo and video hosting sites that all went under. Photobucket is a big one. Eventually the money has to dry up, and services like Cloudflare wont be free unless they turn a big profit.

I'd send them back this link and ask if they value the free use of curl: https://github.com/search?q=org%3Atravis-ci+curl&type=code

Alas, a lot of capitalism is about who can be more parasitic than the other.

Not surprising, given TravisCI's clampdown on free resources. And IMHO it makes sense to have a line there somewhere, at least for "automatically free" (vs explicitly decided sponsorships)

It's certainly surprising to Stenberg, because up until now Travis made a big deal about how much they use curl internally, and generously donated more compute for curl CI.

And look, even if they weren't a huge commercial curl user, passing up a chance to sponsor a foundational library of the internet is such a short-sighted move that I'm actually amazed at them. I'd think companies would jump at the chance of recognition and developer goodwill that would come from sponsoring curl.

You’d think so but the reality is that you wouldn’t hear about it unless they pull the plug on the free CI services.

Travis has had years of abuse of their platform. I’m surprised it took so long to lock it down. I’m sure it’s a PITA for the free tier users to have to reach out to them to get back on there, but hey they get the support they’re paying for.

Plus there’s always GitHub Actions...

It’s a good enough rule for an “automatically free” tier. The criteria has to be something.

Manually approve the OSS that had paid devs.

I bet SourceHut ( https://builds.sr.ht/ ) would be a good fit.

The part that surprises me is that anybody uses travis anymore? I figured everyone moved to jenkins like 9 years ago or whenever it was.

We continue to use it, because it offers ARMv8, PowerPC, and SystemZ runners. No other service does this yet.

The writing was on the wall when Travis ci was acquired in 2019. For my own part, that's when I moved away from Travis CI.

Hopefully one of the Linux vendors can pick this up:

“Another option would be to use the curl fund to pay for travis. pricing. $129/month "2 Concurrent plan" is probably roughly the setup we had?”

Are there any half-decent ways to run CI locally? Anyone have any suggestions?

For me it doesn't have to be automatic like these CI services.

Gitlab CE? Should be a Docker pull away.

Agreed with this, because it gives you a relatively direct upgrade path in case you want to start using GitLab Enterprise.

Sorry if I'm ignorant, but isn't running CI locally basically just running tests/build normally?

It's the opposite of running tests locally. You don't want to test in your development environment. That's how you get into "runs on my machine" syndrome.

Wouldn't running tests in docker on a fresh image creation solve this ?

Sortof. However, if you have a local file which hasn't been committed to VC, then you'll only notice this when you push to CI.

This is probably the biggest benefit for me, it means that the build/testing/infra is reproducible on at least one other machine.

If you're on Linux, sure.

They literally said they want to do this locally though.

Well, you'd need to manage multiple OS/architecture configurations, and keep them separate from your dev environment. I'm sure it's all possible with qemu etc, but having (a) somebody else do that and (b) actual hardware instead of a VM-on-emulator cludge, is a game-changer

Concourse CI. Easy to install locally and you can define pipelines to do ... stuff.

It does stuff you’d normally do with Travis or GitHub actions. Store them as code in your project repo, run jobs automatically and repeatable and do stuff based on the results.

Ugh. Concourse is interesting for sure, but really hard to get a hang for. I would be careful who I recommend it to.

I don't like to speak in negatives so I won't elaborate, but basically I've had a very hard time using it and it made work miserable. Besides the shiny UI, there was literally nothing to make a devops team's work easier. Simply accessing a failed job log output was hard.

I prefer gitlab-ci because I already use gitlab and the integration is nice. For a pure CI system I would use drone.io if I was not already using gitlab.

I spent a few hours this week creating a FreeBSD port for Drone, only to find out that the OSS version of Drone doesn't support external workers and since FreeBSD doesn't do Docker, Drone is pretty much useless on FreeBSD. It would be great if it was mentioned in their documentation so I didn't waste my time with Drone, but it's not. Concourse on the other hand seems to work on FreeBSD and doesn't have artificial limits to try and sell something.

Tons of ways that are all quick and easy to set up... if you build on one platform, or use VMs of one OS only, or use Docker containers.

As soon as you need e.g. macOS + Windows + Linux + iOS + Android (really, any three of those) it's hell. You're either going to be conforming your build to the requirements of some "cloud" solution (if you can) while paying painful money for it and maybe (likely) not even getting very good performance in exchange, or maintaining several build machines (locally or as rented servers/VMs or whatever). Or screwing around with Parallels or something, and "enjoying" bad build times for most platforms.

It's a very easy problem to solve for container-heavy web stuff. It becomes no fun in a hurry once you're very far outside that.

www.gocd.org

See build.gocd.org for an example of what pipelines can look like

You mean host your own CI? Or just run your tests on your machine that you’re developing.

The latter is super easy. Read the readme and run the tests.

The former can be done with any of the popular open source CI platforms. Jenkins, Drone.io, Concourse, or GitLab runners to name a few.

I'm sure it's a change from how it worked before, but I don't see the real problem. If you can afford to pay developers, you can probably afford to pay for CI. They don't have to offer a free tier at all.

If you charge people for your service, maybe you can pay for cURL.

Reasonable in the case of curl particularly, but people are acting like it's a bad policy for all projects.

Reply on news.ycombinator.com