The new pricing model for Travis CI • Hacker News Board

Re: The new pricing model for Travis CI

#41

Post by matharmin » Mon, Nov 02, 2020, 8:09 AM UTC

jrockway wrote: post #8

I guess this is the same pricing model as CircleCI? I've always found "build minutes" to be a little bit of a vendor-favored pricing model. I really love wanting to do a release, and watching my CI provider take three minutes to pull down a 30MB docker image, or "npm install" running at dialup speeds. All while they're billing you per minute -- they make money by not investing in their infrastructure! I'd prefer to p…

While I see the mismatched incentives here, I believe they have enough other incentives to make builds faster. I gladly switched over from the concurrency-based pricing to per-minute pricing on CircleCI when it became available. This ended up being significantly cheaper for me, and I never have to worry about how many builds I'm running in parallel.

Re: The new pricing model for Travis CI

#42

Post by clashmeifyoucan » Mon, Nov 02, 2020, 8:28 AM UTC

softinio wrote: post #25

clashmeifyoucan wrote: post #19

I'm wondering if there's still a solid reason to use Travis for new projects. I can't be bothered to move my current builds from there to GitHub Actions, but for future projects GitHub Actions seems way more lucrative to use. I think both pale out in comparison to GitLab CI however, it's a pity GitLab is less popular.

I like Gitlab and I tried them for a year before moving off of their CI couple of years back. Main reason was their CI was slow and had some reliability problems at the time. Hopefully they have resolved those by now as I would like to see more adoption of their service for sure. Will give them another shot soon :-)

I recently found a comparison¹ which was interesting. Of course, it's gitlab's so take that as you will.

[1] https://about.gitlab.com/devops-tools/github-vs-gitlab/#comp...

Re: The new pricing model for Travis CI

#43

Post by [deleted] » Mon, Nov 02, 2020, 8:54 AM UTC

tbodt wrote: post #31

TL;DR: Travis CI is no longer free for open source projects. Instead you get a free trial good for 1k build minutes, and can email them to beg for more when those run out.

[deleted]

Re: The new pricing model for Travis CI

#44

Post by Master_Odin » Mon, Nov 02, 2020, 9:02 AM UTC

clashmeifyoucan wrote: post #19

I'm wondering if there's still a solid reason to use Travis for new projects. I can't be bothered to move my current builds from there to GitHub Actions, but for future projects GitHub Actions seems way more lucrative to use. I think both pale out in comparison to GitLab CI however, it's a pity GitLab is less popular.

Not really, and hasn't been for a while, assuming your hosting your code on GitHub or GitLab. Both offer a service that is comparable to Travis, and are much better backed at this point after the acquisition of Travis and gutting of their staff.

The only thing I sometimes miss from Travis was the ability to run "debug" builds, but most of the time this was necessarily only because of how omnibus their VMs were and oddities of pathing.

Re: The new pricing model for Travis CI

#45

Post by marco_craveiro » Mon, Nov 02, 2020, 9:29 AM UTC

softinio wrote: post #23

Think the wiser options for OSS are Github Actions & Gitlab CI going forward. I have heard good things about Azure pipelines too. After travis-ci got bought and layed off a lot of key staff I did think the day would come where they will no longer will be the defacto choice for open source and I think this news confirms that day being today :-)

I've been postponing moving to Github actions, but I guess now I have no option!

Re: The new pricing model for Travis CI

#46

Post by takluyver » Mon, Nov 02, 2020, 9:37 AM UTC

ivirshup wrote: post #17

Can anyone comment on how these changes are going to impact projects like conda-forge, which use the free compute time to build binaries? My reading is these projects are what's being targeted. Perhaps there are more egregious uses of their servers?

It looks like conda-forge currently uses Travis only for ppc64le builds. I'm not sure if any other free CI services offer PowerPC support - if not, it's likely to impact PowerPC support (also in many other open source projects). However, an IBM blog post in July said they were providing the servers through Travis free for open source projects on GitHub, so possibly they will agree some way to continue to offer it.

Re: The new pricing model for Travis CI

#47

Post by geerlingguy » Mon, Nov 02, 2020, 10:09 AM UTC

brandur wrote: post #15

rgovostes wrote: post #6

Earlier quoted context omitted.

Travis CI and GitHub both use MacStadium's infrastructure for macOS builds, not their own. https://www.macstadium.com/customers/travis-ci

That's fascinating – I always wondered how exactly Travis was running their Mac OS builds. Based on MacStadium's public pricing, which is $150/month for the base model of the latest Mac Mini, this cannot be cheap for Travis, especially given they offered (past tense) Mac OS builds for free. Not surprised to see them start charging more, but it's coming at exactly the wrong time given that GitHub (with Actions) is now…

MacStadium also offers some types of virtualized macOS environments, even a Kubernetes-on-Mac offering. So I'm guessing it's not all individual Mac minis running these builds... at least I hope not!

Re: The new pricing model for Travis CI

#48

Post by konschubert » Mon, Nov 02, 2020, 10:29 AM UTC

Travis is changing from growth mode to milk-the-melting-ice-cube mode.

That’s why they are turning off free foss builds.

Re: The new pricing model for Travis CI

#49

Post by tikej » Mon, Nov 02, 2020, 10:33 AM UTC

Finally! This change gives me necessary motivation to switch to fully open source alternatives (probably Drone).

Re: The new pricing model for Travis CI

#50

Post by brmgb » Mon, Nov 02, 2020, 10:39 AM UTC

matharmin wrote: post #39

solatic wrote: post #36

Earlier quoted context omitted.

> slow CI is probably the biggest engineering time killer in existence If you're at the size where slow CI negatively affects your projects, then you're big enough to own your own CI (at least the build agents). Remember that one-man projects don't need CI, and that CI for small (n<5) teams is almost never the bottleneck. These SaaS CI providers really target the open-source / small-team market and it makes sense tha…

I disagree with this. Even a single project with 20-minute build times is enough to slow down or frustrate development. At the same time, I would not easily justify spending time managing CI infrastructure with my team of 6-10 people. Things may have changed since then, but the last time I self-managed build agents, it often lead to build jobs being tightly coupled to the build agent and installed software versions.…

> At the same time, I would not easily justify spending time managing CI infrastructure with my team of 6-10 people.

The step from a docker-based build to a proper build agent is a small one. From there, running your CI yourself on a cloud provider is not particularly hard and at size will quickly be cheaper than having an intermediary.