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

The new pricing model for Travis CI

blog.travis-ci.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: The new pricing model for Travis CI

#51

Post by darekkay »

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 using GitLab CI and Travis CI interchangeably. But the recent cut to 400 pipeline minutes on GitLab CI might make it less attractive than Travis CI, even after the current change.

EDIT: Travis seems to take 10 credits per minute, with 1000 free credits per month. So it seems to be the least generous tool with 100 minutes per month vs 400 (GitLab CI) and 2000 (GitHub Actions).

Re: The new pricing model for Travis CI

#53

Post by kevingadd »

solatic wrote: post #36
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…

> 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…

Every project I've worked on at Google and Microsoft has used cloud CI services at least in part - travis, etc. My current team had a custom jenkins instance + agents we maintained and we've phased them out in favor of the cloud. It just scales better and the time our team spent maintaining agents can now be spent on writing code and fixing bugs (we do still have people who do work to integrate with the cloud CI services, but it's considerably less)

Re: The new pricing model for Travis CI

#54

Post by dnsmichi »

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 :-)

Hi, Developer Evangelist at GitLab here.

OSS projects are eligible for a free Gold plan on GitLab.com and can benefit from more CI minutes: https://about.gitlab.com/solutions/open-source/

If you are planning to continue using GitHub, you can also integrate with GitLab CI/CD for your OSS project: https://about.gitlab.com/solutions/github/

Re: The new pricing model for Travis CI

#55

Post by mariusor »

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 think that for Open Source projects the better CI is still SourceHut. They're not currently limiting any of their resources for free accounts, relying on the funding from paid accounts to pay for their resources.

I find this pay it forward model better than any other option.

Re: The new pricing model for Travis CI

#56

Post by jdboyd »

solatic wrote: post #36
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…

> 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…

One man multi platform projects strongly benefit from CI to test the other platforms.

Re: The new pricing model for Travis CI

#57

Post by Spivak »

dinkleberg wrote: post #4
mushufasa wrote: post #2

i wonder if there are actually higher costs associated with macOS, or if this is just segmentation based on the fact that macOS users are more willing to pay more for software

Building Mac build farms is way more of a pain and absolutely costs more. There are a few services dedicated to making it easier, but Apple isn’t trying hard to make people’s lives easy in this.

At least they're not being litigious about small shops using hackentosh VMs for CI because sticking a bunch of Mac Minis in a rack technically works but seems super silly.

Re: The new pricing model for Travis CI

#58

Post by nickjj »

alexellisuk wrote: post #38

For OpenFaaS (and other projects - k3sup, arkade, inlets etc) paying for Travis isn't going to be an option, as they are open source and unfunded. The Travis platform means being able to have relatively portable CI that almost never needs to change because of the CI platform. Bring a Makefile and use it locally and in the build pipeline. Moving off Travis to something like GitHub Actions will cost a significant amoun…

> The Travis platform means being able to have relatively portable CI that almost never needs to change because of the CI platform. Bring a Makefile and use it locally and in the build pipeline.

What if you defined your GitHub actions to call out to shell commands? Then there's very little that's specific to GH actions.

Actions are nice but personally I'd rather have my CI as generic as possible, especially for the reason you mentioned which is to be able to run things locally if needed.

Re: The new pricing model for Travis CI

#59

Post by aaron42net »

darekkay wrote: post #51
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 using GitLab CI and Travis CI interchangeably. But the recent cut to 400 pipeline minutes on GitLab CI might make it less attractive than Travis CI, even after the current change. EDIT: Travis seems to take 10 credits per minute, with 1000 free credits per month. So it seems to be the least generous tool with 100 minutes per month vs 400 (GitLab CI) and 2000 (GitHub Actions).

Where did you see the "per month" for Travis? The 10,000 free credits are a one-time trial from what I can see.

Re: The new pricing model for Travis CI

#60

Post by danpalmer »

danielheath wrote: post #13
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…

This is why I strongly prefer BYO-agents systems (github actions, buildkite, jenkins). I got our CI pipeline from 90 minutes to 10 minutes by running parts in parallel and applying lots more hardware. The cost is essentially nothing ($0.10 / build) compared to the time developers spend waiting. I currently use & recommend buildkite because they offer a preconfigured cloudflare template that does all of the hard parts…

It's funny, this is almost exactly the argument we used to switch to non-BYO systems – moving from Jenkins to CircleCI.

We had Jenkins, but it required so much engineering time to manage, secure, upgrade, etc. Then when we hit scaling limits as our team grew, scaling it out to multiple machines took more time and cost a significant amount as we had to have capacity for peak time, which when all engineers are in one timezone is a significant peak compared to, say, the weekend.

We moved to CircleCI and while I have many frustrations with it, parallelism and ability to speed up the pipeline with minimal development overhead are not really frustrations I have. The cost is also minimal compared to the developer time, and while we're getting "less for our money", because we only pay for the active time, it's actually cheaper for us than Jenkins was just for hardware rental, let alone developer time managing Jenkins.

I can completely see how a different org with different constraints, different deployments, clouds, strategies, provisioning, distribution of engineers, etc, could come to the conclusion that you did – that BYO is better, but I think it does depend on so much.

Post reply on HN