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

https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works

by geerlingguy • 6 years ago

214 142 6 years ago

draw_down• 6 years ago

I just spent the past 6 hours migrating some of my open source projects from Travis CI to GitHub Actions

Man. Sounds like my personal hell.

I’ll never understand how people motivate themselves to run projects. When I think about it I just envision doing a bunch of crap like that, dealing with issues people file, etc etc. No thank you.

jfim• 6 years ago

Pretty much any time there's an acquisition of a company, followed by a firing of a significant fraction of the engineering staff, one should run away from it.

Sucks though for Travis CI users, I used it in the past and it worked well.

tasogare2• 6 years ago

For almost a decade, Travis CI made it possible for me to build—and maintain, for years—hundreds of open source projects.

Then what about paying for it? The service is definitely very valuable to this person.

lykr0n• 6 years ago

This. If I had a cloud hosted CI tool, I would gladly allow open source projects to use it. But they would be lowest priority and there would be limitations on how often builds could happen and/or volume of contributions.

Large corporate backed opensource projects should absolutely be paying for tools like Travis CI. Just because it's open source doesn't mean there isn't money floating around.

It's not super hard to rent a VPS or Physical Server somewhere and spend a few hours setting up <insert ci tool of your choice).

geerlingguy12• 6 years ago

It's not the setting it up that's preventing someone like me from self-hosting these kinds of tools. It's the maintenance, security, accessibility, etc.

More time on all that (or risking hacks and having more downtime) equals less time actually working on the projects being tested.

azdle6• 6 years ago

Well, their lowest paid tier is $69/month. I dunno about you, but that's way more than I can justify spending to be able to support doing work for free. If they had a $50/year or so plan that just restored the previous open source plan, I'd be more willing to consider something like that, but >$800 a year puts it firmly out of my price bracket for what it offers me.

geerlingguy12• 6 years ago

This. I am willing to pay but there's no way I can spend my yearly "save for a new laptop every couple years" budget on one SaaS for projects that generally contribute $0.00 to my bottom line.

geerlingguy12• 6 years ago

The point is, like with almost all open source work, the funding has to come from somewhere.

If I'm an open source software maintainer, and I make a project that is used by 3,000 companies, helping them generate $Xmm in revenue... how much of that money ever trickles back to the maintainers? The typical answer is $0.

Some maintainers are lucky to have some form of corporate sponsorship, others spend many cycles on some form of marketing to build up some kind of financial support (tip jars, Patreon, etc), but the pricing for Travis is astronomical for non-enterprise usage.

But as I said in the post, I'm grateful for what I got for the 8 years I had it. And I'm happy that GitHub/MS is now running with that gauntlet.

mtlynch• 6 years ago

Reading your post, I realized that I'm a company (albeit a very small one) that profits from your work and doesn't pay you.[0] I use your Nginx role in my open source product[1], and I use several of your other roles in my development environment. I just signed up as a monthly sponsor.

Thanks for your fantastic contributions to the Ansible ecosystem and to open source in general. Apologies for my past freeloading!

[0] https://mtlynch.io/retrospectives/2020/11/

[1] https://github.com/mtlynch/ansible-role-tinypilot/blob/b56c1...

renewiltord• 6 years ago

Interesting. You put in work, Travis CI puts in work, but the surplus accrues to a third-party. Hmm. Unfortunate.

It's possible that most OSS won't have CI servers in the future. I don't imagine that's the end of the world but it does suck.

tasogare2• 6 years ago

Then your are in a position similar to Travis until now: offering a lot of value for free. You need to find a way to monetize the project(s). Only one of all those companies need to give 100 bucks a month to pay for the CI + extras.

f311a• 6 years ago

I think everyone should move from Travis CI, especially private repos. Idera bought the project that has no future, and it wants to get the money back. It won't get any better.

Idera has fired a lot of Travis CI engineers, and your private repositories are now at risk. They can save some extra money on security.

ishcheklein• 6 years ago

We had been paying ~$500/month for the open-source project (https://dvc.org) even before this new pricing model, and migrated to GitHub Actions recently- works like a charm. The only issue that we have now is Windows builds- machines on GH have a bit less resources, but it's good for us to optimize it anyway.

sounds2• 6 years ago

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 do. No one wants to learn the custom setup steps, not even for the "biggest" of the bunch. (Is that still Github? Who knows? I don't.)

Oh, and if or when I migrate away from a CI system, like right now... Good thing I just kept it simple, you know?

Even for builds that target Windows, I just run a shell script.

I get it that Node and Rust builds really benefit from the advanced features. Anyone care to comment - is it as portable as a shell script?

steveklabnik• 6 years ago

I don’t think either of them really “benefit from the advanced features” any more than any other language. Also, both have builds that are generally more cross platform than a shell script, given that they’re native on all platforms, and shell is not.

monkeybutton3• 6 years ago

do the minimum with these CI integrations to get my shell script to run

This. 100%. Where I'm working is migrating from Bamboo to Jenkins. For my team the new process is just calling "./build-test $params" while others are stuck re-implementing various stages, tasks and blah blah blah. Also an added bonus to this is having the full history of changes to the CI/CD process tracked in git.

redis_mlc• 6 years ago

I call mine make.sh.

Now get off my lawn!

est312• 6 years ago

while others are stuck re-implementing various stages, tasks and blah blah blah. Also an added bonus to this is having the full history of changes to the CI/CD process tracked in git.

Can't those stages, tasks, etc. be specified in the CI specific config files of the repository? Specifying them via an UI seems horrible to me. At least Github actions is all file-specified (except for secrets).

InsaneOstrich2• 6 years ago

Are you moving to Jenkins because of the recent Atlassian license changes?

merb• 6 years ago

btw. even gitlab does that with their autodevops, besides that they create gitlab-runner:

https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla... https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla... https://gitlab.com/gitlab-org/cluster-integration/auto-deplo...

I found these fascinating, I mean they still have lots of things in their ci file, but basically the have tons of shell scripts that would work without their gitlab-runner.

Not affiliated with gitlab I just tried to figure out how some of their stuff works to have the same k8s integration than their autodevops offers.

geerlingguy12• 6 years ago

Makefiles are the gold standard there, warts and all.

But in every case, unless you encode a whole plethora of hacks in your golden build script, you still need minimal environment setup, like Python + Docker + [insert library here].

Most of my Travis files are only 10-20 lines long, but I work in a lot of different types of environments, so it's not always as easy as "three lines of bash and a docker run command".

Plus I have a number of legacy projects which did use some of Travis' more exotic features, and those will take longer. Not just for myself, but I'm thinking of tons of smaller OSS libraries and projects that are minimally maintained yet have a large footprint under more popular and maintained software!

sounds2• 6 years ago

I'd be interested to have a deeper discussion with you about Makefiles, sometime.

We've actually migrated all our projects off Makefiles. Developers hate having to live within the constraints.

curryhoward• 6 years ago

Small plug: consider using Toast [1] to define your CI jobs. It's essentially Make + Docker. You define whatever targets you want (build, test, lint, etc.) and the dependencies between them in a YAML file, and Toast runs them in Docker containers. You can run your jobs on any machine that has Docker—including CI systems like Travis and GitHub Actions. You aren't locked into any CI system, and you can also run your jobs locally.

[1] https://github.com/stepchowfun/toast

qppo2• 6 years ago

Once you start caring about cross-platform, incremental, distributed builds with a bunch of people committing to a monorepo those advanced features start becoming attractive. Shell scripts handle the 'run this build/test task' but not 'pull these artifacts from another set of tasks, run this task to produce a bunch more artifacts, cache them for later.'

In these scenarios the lines between build system, package manager, and task runner all become pretty blurred. Haven't found an all in one solution that I would call "portable" yet.

emptysea• 6 years ago

Sounds like your describing what I like to call a fancy build system

Something like Bazel[0], Buck[1] Pants[2], etc. One of their main features is robust caching of build artifacts, which is helpful for larger projects. But they require some major investment compared to your typical `scripts/build.sh`.

[0] https://bazel.build [1]: https://buck.build [2]: https://www.pantsbuild.org

DrBazza• 6 years ago

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.

hinkley3• 6 years ago

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?

__s• 6 years ago

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

azdle6• 6 years ago

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 more than I can justify. I've also got plenty of compute laying around if anyone has suggestions for something self-hosted.

rochak2• 6 years ago

Have you looked into CircleCI?

azdle6• 6 years ago

I've used it in the past, but when they finally killed off the 1.0 builders (?) my company went to an "internally" hosted Jenkins[1] server and I haven't played with any of the 2.0 stuff. Have you? How do you find working with it?

[1] I did also ask about selfhosted stuff, but I'm not willing to host Jenkins for myself. I've heard nothing but complaints about managing a Jenkins install. It's been fine as a user (if a bit confusing), but I really don't want to admin it.

013a• 6 years ago

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 with Gitlab, has integration with Github.

* CircleCI. Something of a gold standard in CIaaS among growing companies. But, it goes down a lot, and the new UI isn't an improvement. But, it works and its a good value. Word of advice, I'd avoid using their "Orbs" if I were you. You can accumulate a lot of lock-in with those, and they're infamous for stability issues. Instead, use their docker builder and just build a base docker image with all the stuff you need installed.

* Buildkite. Really cool product; they handle the control plane and the UI and webhooks, you host the runners. Its a simple binary or docker image you can install anywhere. If you're looking for something with low lock-in that's still easy to manage, Buildkite is a great option. I'll warn you though: if you're going to do any kind of cloud hosting for your runners, and you want to build docker images, best to avoid their dockerized runners. Just install natively on a linux box, either manually, with an AMI, etc. Docker-in-Docker sucks; not impossible to get working, but not worth your time.

* Jenkins/JenkinsX. If you want something with zero lockin but also hard to manage.

* AWS CodeBuild/CodePipeline/CodeDeploy. There is, like, no one I feel comfortable recommending these options to, but people still use them because they're AWS.

microtherion• 6 years ago

I'm quite happily using a self-hosted Drone (drone.io) instance, though I don't have much experience to compare it with with other CI systems and my use case is probably not the most sophisticated one. Team is quite responsive, especially considering I'm a free tier user.

gmemstr• 6 years ago

Hey, one of the people responsible for orbs (primarily writing and maintaining our first-party ones) - curious if you can elaborate on "infamous for stability issues". Obviously it's hard to argue against the lock in, but I am aware that GitHub Actions has a similar system.

app4soft• 6 years ago

Gitlab CI. Good value, great integration with Gitlab, has integration with Github.

Yep. Now I'm thinking on migrating my AppImage build scripts (Travis CI + Transfer.sh used for my projects on GitHub) from Travis CI to Gitlab CI. Hope, that there is simple "3-step switch" option.

Really appreciate those FLOSS projects which already use "Gitlab repo + Gitlab CI" to build & provide builds/artifacts, e.g. GrafX2[0], Inkscape[1], etc.

[0] https://gitlab.com/GrafX2/grafX2/-/jobs

[1] https://gitlab.com/Inkscape/inkscape/-/jobs

Fabricio20• 6 years ago

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

nicoburns2• 6 years ago

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.

donmcronald2• 6 years ago

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.

shakna• 6 years ago

Sourcehut is something you might want to look at. It's modular, so you use what you use, and ignore the rest.

The CI they offer makes no assumptions about where your repos might live (git is git. Who cares who the host is), and offers the stuff you might need like secrets, ssh keys, etc. The images they supply for testing actually seem more extensive than the other players.

And if you really want to self-host it... Go ahead. The whole of sourcehut is open source and reasonably well documented. You can host your own build server with minimal fuss.

[0] https://sourcehut.org/

azdle6• 6 years ago

Interesting, I didn't know it would support pulling from other git hosts. It looks like their CI even has an API integration with GitHub at least for PRs. That's looking like a potential winner. Thanks for pointing that out.

jhasse• 6 years ago

GitLab CI

azdle6• 6 years ago

I always had insane amounts of queue time on gitlab's CI too. I know they have self-hostable runners, do you know if those work from behind a firewall so I could run them on hardware I have at home?

Also, do you know if it's possible to use gitlab CI as a merge gate on github PRs?

PebblesHD2• 6 years ago

After some of the previous TOS changes, I finally found the motivation to move to a self-hosted CI on a VPS. I’ve been entirely satisfied since migrating, and it’s been a truly low touch experience. Not for everyone I’m sure but for the low cost of the VPS I’m getting my value out of it, certainly not proving to be a maintenance drain as I’d feared, just updating it on a CRON has served me well.

schoen• 6 years ago

Are there good tools to help with this for people who are used to a hosted CI and want to replicate some of its features? (I'm just curious, I'm not in that situation myself.) Or is the cloud/SaaS instinct so pervasive now that very few people are trying to do what you're doing?

PebblesHD2• 6 years ago

If you’re comfortable with AWS or any other VPS provider, there are Ansible and Docker flavours of most common tools. I’m a fan of Jenkins but the competition also offers some well defined pathways to get this going easily, and all of them offer a somewhat similar way to define builds automatically in code. My go-to is the github org scanner plugin that can watch for new repos with a Jenkinsfile, and will happily manage creating the automatic commit hooks if a new one is found giving you a very similar level of ‘magic’ integration to what the SaaS tools offer.

MaKey• 6 years ago

There is Concourse CI [0], which appears to be simple to set up.

[0] https://concourse-ci.org/

jrochkind18• 6 years ago

Oh boy, I just moved my projects from travis-ci.org to travis-ci.com after the builds stopped happening on .org.

(Despite the travis FAQ that said "we’re making a number of changes to the travis-ci.org infrastructure to ensure the service will remain as reliable and available to you as it always has been until [it goes away Dec 31]", that was not the case, builds simply stopped working on .org. https://docs.travis-ci.com/user/migrate/open-source-reposito...)

I actually had not seen that announcement at all, this is the first I'm seeing it. So I'm in the same position as OP, I maybe should not have spent time migrating my projects to travis-ci.com. Although I guess this buys me a bit of time to move to github actions instead.

Travis is the reason that many people DO CI at all, in my experience. They made it so easy -- and free for open source -- that there was no reason NOT to do it. Then once you see the value of it, you are hooked, you can't do without it. But I think the number of projects doing CI (open source and not) skyrocketed because of travis. Prior to travis's entry on the scene, CI was not nearly as universal as it is now.

So to say that offering free CI to open source is "unsustainable".... I dunno, they managed to do it for 9 years, were they losing money the whole time?

I think the free service for open source literally created the market. Or expanded it exponentially. It was the first exposure a lot of people had to CI, and they took that first step because it was so easy and free.

And now we're hooked. If there weren't other free alternatives like Github Actions, I don't know what open source would do... we all know we can't develop this stuff without CI, but so many open source projects simply don't have a budget for it.

geerlingguy12• 6 years ago

All three companies I worked for that ended up paying for a beefy Travis CI enterprise plan did so after getting hooked through the open source offering and wanting more concurrent runners and faster builds.

Without that funnel, and knowing it's all integrated deeply in both GitLab and GitHub, I wonder where Travis CI could ever expect growth again... but that's probably not the end goal anymore, just milking the current paying clients and maintaining the status quo.

jrochkind18• 6 years ago

"that's probably not the end goal anymore, just milking the current paying clients and maintaining the status quo."

Yep, that's private equity. I won't forget it again.

If it makes less and less profit every year even that's probably fine, eventually they'll shut it down, as long as they made back a multiple of what they paid by that point, then it was a good investment.

It's sad to me just as an engineer, that travis is actually really well-built product, it works magnificently and sets a high bar for ease of use, because of many hours of work that developers who cared put into it... and it's now just going to be allowed to slowly sink into the sea.

mschuster91• 6 years ago

I dunno, they managed to do it for 9 years, were they losing money the whole time?

Probably. Many "startups" these days are not profitable for years as they burn mountains of VC money to gain market share and drown out competitors.

account42• 6 years ago

we all know we can't develop this stuff without CI

Of course we can, we just down't want to.

jrochkind18• 6 years ago

True. We have just learned what an advantage CI is to software quality and developer productivity, expectations for both of which have been raised because of pervasive use of CI.

Many people wound up discovering/learning that and raising expectations because Travis's extraordinarily easy-to-use and reliable, and free for open source service, got them to try it out and discover the benefits. People had been talking about how everyone should be doing CI before travis, but I think travis played a major role in significantly increasingly how many people were actually doing CI (and thus learning that they didn't want to do without it's benefits), changing the way software is developed. Which is to the credit of those who developed the original travis service, for sure.

I think it really created a market, by offering something with very low barriers that 'hooked' people. Now we're hooked.

hinkley3• 6 years ago

Lately as I’ve been getting (more) frustrated with Bamboo and spending time noodling with kubernetes and JAMStack. I keep flirting with the notion that there’s a new generation of CI tool out there waiting to be discovered, one that steals a bit of brain- and problem-space from all three.

One that could more easily be set up by individuals, making it amendable to open source, possibly with some small degree of federation.

rosineygp• 6 years ago

I had to change CI many times.

From jenkins to gitlab... From travis to github actions...

So I build this small project that helps me to change faster without touch in real CI logic.

https://github.com/rosineygp/mkdkr

I think your problem is bigger than mine, but this kind of approach can help you in the future.

weka• 6 years ago

Not surprised.

Travis CI is owned by Idera, Inc. who also own Sencha who make Ext.js -- a pay-to-use JavaScript framework.

First thing they did when Idera, Inc. bought Travis CI? They gutted the Travis CI team.

segmondy• 6 years ago

That's Idera, if they buy anything you use, run!. Private Equity is all about milking the cow till the cow dies.

vosper3• 6 years ago

who also own Sencha who make Ext.js -- a pay-to-use JavaScript framework.

I pity anyone who's paying for Ext.js (self-described as "The Best JavaScript Framework In The World"). That is some ancient shit right there. They must have some poor sods who're really, truly, stuck if they're managing to get people to pay for it. I guess at least you get support in your quagmire. But good luck finding quality developers who want to work on an Ext.js project...

Joeri• 6 years ago

I worked with extjs 2 and 3 for years and honestly productivity was as high or higher than angular or react. It was a game changer and allowed us to build things an order of magnitude faster than before. I really liked it. What it lacked was a good responsiveness story, and by the time they added that I was already gone, first to backbone and later to angular and react.

The amount of vendor lock-in of Extjs is massive though. It had its own JSX-like pseudolanguage for describing UI that was impossible to port to anything else. Moving away meant a total rewrite.

TylerE• 6 years ago

While I have some sympathy. I also think that expecting travis-ci to effectively donate hours and hours of CPU time a month to endlessly run tests on hundreds on minor projects from one guy is exactly why this change happened. It's unsustainable.

imroot• 6 years ago

This "one guy," if you will, is responsible for a majority of the ansible galaxy modules that are out there.

Far from a bad actor just utilizing CPU time for pet projects, Jeff's code is probably in use in a large majority of companies that use Ansible, mine included.

longcommonname• 6 years ago

How much money does your company contribute to Jeff?

user59944612• 6 years ago

Nitpicking here, the vast majority of companies that use Ansible do not use galaxy.

hacker_newz• 6 years ago

I don't know how the author could expect a free build service to last forever.

geerlingguy12• 6 years ago

I don't. And as I said in the post, I'm extremely grateful for what I got.

I was already migrating projects for a while, and long term may even go back to a local server for builds if GitHub pulls the rug out too. But allowing a service to manage the build system for me saved/saves a good chunk of time.

jrochkind18• 6 years ago

The HN thread from when Travis's purchase by Idera (private equity) was announced, Jan 2019:

https://news.ycombinator.com/item?id=18978251

I had pretty much already learned that "bought by private equity" means "run away as fast as you can, they are going to gut it", and I suspected as much from the travis purchase... but I didn't take action, hoping it would not be true, and not wanting the work of moving projects away. Next time I'll remind myself, no, really, you know what "private equity" means, start looking for an escape now on your own timeline before circumstances give you a deadline.

geerlingguy12• 6 years ago

I mean, I expected this to happen, but with some amount of lead time. In this case they literally made the change the night before they announced it!

gregors• 6 years ago

and subsequent layoffs posts

https://news.ycombinator.com/item?id=19218036

That's when I started recommending clients make plans to move to another provider

throw_m239339• 6 years ago

Travis CI wasn't going to remain "free" forever, especially with the new owner (which owns Sencha as well). They want to make a profit, open source free builds are not making a profit.

paledot• 6 years ago

Should you want to apply for these credits please open a request with Travis CI support stating that you’d like to be considered for the OSS allotment. Please include:
Your account name and VCS provider How many credits (build minutes) you’d like to request (should your run out of credits again you can repeat the process to request more or discuss a renewable amount)

Sounds like a tedious, repetitive process. If only there were a way to automate creating support tickets on a schedule...

xvilka• 6 years ago

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/images/...

capableweb• 6 years ago

At a glance, it doesn't seem to support neither Windows nor OSX, any ideas if it is supported with your own builder/runner or if sr.ht is working on supporting it in the future?

boris• 6 years ago

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.

jrochkind18• 6 years ago

Travis has an FAQ whose URL says "open source repository migration", but whose on-page title says "Migrating repositories to travis-ci.com"

Travis Staff accounts in the travis "community forum" were linking to this FAQ as recently as 9 days ago, which still at this moment contains a question:

Q. Will Travis CI be getting rid of free users? #
A. Travis CI will continue to offer a free tier for public or open-source repositories on travis-ci.com and will not be affected by the migration.

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

This would seem to be grossly misleading, if not simply wrong info? There are still a bunch of travis users on travis community forums trying to figure out what's going on and why travis-ci.org seems to have stopped working (also different from what the FAQ says), who don't seem aware of the pricing change.

The first line of the document is "On May 2nd, 2018 Travis CI announced that open source projects will be joining private projects on travis-ci.com!", which also includes this FAQ:

Q. Will there be lower concurrency for free accounts on travis-ci.org?
A. As part of the shift of infrastructure from .org to .com and needing to make sure all users have equal access to resources, free and open-source .org accounts will have concurrency reduced from 5 to 4 concurrent jobs. Concurrent jobs have not changed on .com, so please consider migrating your repositories as soon as possible if this is an issue.

So... that's all not quite right, it turns out. They're providing an FAQ about "free accounts" without saying there no longer is no such thing as a free account, and "open source projects" are "joining private projects on travis-ci.com" only in the sense they can choose to pay for the same plans as private projects.

It's true that nobody owes us anything for free, and the free support for open source CI for the past 9 years has been a gift...

It's also true that they are not being particularly transparent (an understatement; if they don't fix that FAQ soon I'm just going to call it lying) or gracious in how they are handling this transition, for an open source community that has come to rely on them.

geerlingguy12• 6 years ago

This is what hurt the most. I knew the migration to .com was happening. And I expected the perks (like 5 concurrent jobs) to be slowly removed over time.

But to go from the status quo to 1000 build minutes and that's it in one day, with literally no lead time.

That's what caused the wincing. I'm sure many of the engineers who were laid off at Travis after the buyout are shaking their heads this week.

jrochkind18• 6 years ago

I expected perhaps they would eventually limit the number of build minutes you got per month.

I honestly did not expect they would eliminate free CI for open source altogether. With virtually no notice. Many people STILL haven't noticed the announcmeent, the FAQ is still misleading them.

yorwba• 6 years ago

They're providing an FAQ about "free accounts" without saying there no longer is no such thing as a free account, and "open source projects" are "joining private projects on travis-ci.com" only in the sense they can choose to pay for the same plans as private projects.

https://travis-ci.com/plans

Was the "free plan" added after you commented?

Free Plan
Free
- 10000 Credits
- Unlimited unique users
- Private & Open-Source Repos
- Windows, Linux, MacOS

takluyver• 6 years ago

As a logged in user, that redirects to a settings page where you can choose your plan. A tooltip has some more detail for the free option:

Free Plan is trial plan. The credits will not be replenished.

It's not clear if that's actually true - some people have had emails suggesting there are 1000 free credits (100 minutes on Linux) per month.

jrochkind18• 6 years ago

Mouse over the (?) icon. "Free plan is trial plan. The credits will not be replenished. Switch to Free Plan if you want to cancel your subscription."

So, yeah, there is something they call the "free plan". If gives you 10K "credits" that once they are gone they are gone (I'm not sure exactly what a "credit" corresponds to in terms of workers/minutes, but could probably find it somewhere).

Do you feel like this is what you expected it to be, that they are being transparent about the fate of open source projects that previously had free CI? You can say you do, it's your perspective!

linsomniac• 6 years ago

Thanks for this pointer, Jeff. I just spent some time adding another test in travis-ci on one of my projects, and this HN post got me to go in and set up the Github actions and badge. Side effect: The test ran in 1 minute on Github where Travis-CI took ~20.

hvaoc• 6 years ago

How about GitLab and your own runner ?

luord• 6 years ago

It might be because I'm more familiar with the syntax, but I find gitlab-ci easier to reason about than github actions. At least, it's a single file instead of a workflow and any number of actions.

This is to say, if I were in Jeff's situation, I would seriously consider moving to GitLab (with mirrors in github for visibility), or at least setting up their ci to trigger from github.

Though maybe I'm just speaking from lack of experience, as I've only set up actions in one project so far.

Faaak• 6 years ago

I love gitlab-ci for this exact reason: you're not vendor-locked-in in any way. Running out of credits ? Just run your own gitlab-runner.

jwilk• 6 years ago

The new pricing model announcement on HN:

https://news.ycombinator.com/item?id=24964601

Fizzadar• 6 years ago

Did not know about the pricing change (no email or any attempted communication it seems). Will be moving to GH actions immediately, bye bye Travis.

edem• 6 years ago

Travis is trash anyway. I've switched to CircleCI years ago and I'm happy with it. Also completely free. PS: I'm in no way affiliated with CircleCI, I'm just a happy customer.

hannob• 6 years ago

It seems to me if it takes you many hours to migrate your project from one CI provider to another you're doing things wrong.

Ultimately your .travis.yml file is a proprietary format for a service that you have no control over. You probably shouldn't have built your project's future on the assumption that it's always available.

Ideally you should have your own testing infrastructure in scripts or test frameworks. And your travis file shouldn't do much more than installing dependencies and running the stuff that's under your control. Put all the logic into the stuff you can control - and next time you find out that your favorite CI provider is no longer nice to you you simply use another one, the migration should not take more than a few minutes.

geerlingguy12• 6 years ago

That's exactly how I have 95% of my travisfiles configured (15 or so lines to describe Travis config and install a couple deps, then '[testtool run]'. But I have over 200 projects to finish migrating.

IceWreck• 6 years ago

The travis-ci.org website still lists this lol,

"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."

abnercoimbre• 6 years ago

My heart skipped a beat. Why is it extremely difficult to be honest about wanting to make a profit one day?,

abathur• 6 years ago

Frustrated by this as well.

Have spent several days over the past few months working on a reimplementation of Nix support to make it possible to wind down "community" support without forcing projects to find a new CI.

Feels like a lot of wasted effort. :/

Havoc2• 6 years ago

But why move to another CI provide that will be under the same commercial pressures ultimately? (Handing out free compute is bad for profits).

As someone pointed out here the other day. With build minutes as a concept they're inherently incentivized to keep old slow gear running as well.

I reckon self-hosted gitlab is a good bet, but admittedly tricky for big FOSS projects that need to be public

user59944612• 6 years ago

Because it's easy to use, it works well, and when it doesn't there are 3 other competitors ready to take over.

Travis CI could shutdown overnight, there's Circle CI and AppVeyor doing the exact same thing. They take pretty much the same configuration so there's nothing to adjust.

Havoc2• 6 years ago

and when it doesn't there are 3 other competitors ready to take over.

Apparently the transition is painful enough to warrant a sizable hn discussion though.

dawnerd2• 6 years ago

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.

toasted_flakes2• 6 years ago

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

dawnerd2• 6 years ago

Good question. Running the old version will still work for the foreseeable future. Since it's on github Im sure someone would just fork it anyways.

Also just noticed I'm running a really old version.

Seb-C• 6 years ago

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.

toasted_flakes2• 6 years ago

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

geerlingguy12• 6 years ago

Each one takes a few minutes (even with automation doing the lion's share of the groundwork). I have migrated around 130 repos so far, and have somewhere between 40-50 left. Some of the last ones actually used more of Travis CI's environment features, so they'll take longer to migrate.

physicsguy• 6 years ago

It's a real PITA isn't it.

One thing I will say - I like the way that you've done your migration. I'm very wary of using defined actions written by GitHub or otherwise, because it seems to me that it leads to vendor lock in for CI.

geerlingguy12• 6 years ago

Ditto, plus it's hard to lock in versions for specific 3rd party actions and keep them updated. You either get 'latest' and hope the 3rd party is trustworthy, or you have to enter in SHAs.

Znafon• 6 years ago

I don't understand this reaction and the reaction of many people in this thread. To me it looks like choosing beggars, maybe I'm missing something.

Travis-CI was giving a ton of computing power for free, no questions asked. That was incredibly generous but had certainly a gigantic cost and it powered many OSS projects for a long time.

Yet how can we complain that they can throw money around, some says that it will reduce the number of new users that discover the service and the number of paying client in the long run (many are saying this but are not paying users anyway) but it's not like the number of potential clients is unlimited anyway and at what point it becomes to costly to get the last ones.

Why would this be a "private equity" thing, you can't always loose (or invest to get more users) money. Does your company sponsors the infrastructure of that many OSS projects? Would it be willing to cover the costs of all servers used by OSS projects for Travis?

jpalomaki• 6 years ago

Not sure if would work, but it might be worth trying to have some kind of "donate CI time for this project" button on the platform.

Could be onetime payment or a recurring donation (charged together with whatever payments you have for the platform).

cactus2093• 6 years ago

There’s a lot of things Travis ci could do. This is a great idea to help offset their costs, they could also have made their platform better to bring in more paying companies. They haven’t at all kept up with competitors as tooling and build processes have evolved in the past 9 years (namely easy to use docker-native test environments, and parallelization options for big codebases).

I agree with the parent comment, it’s bizarre to blame this on the new acquiring company and to be mad about this development. Travis ci has been asleep at the wheel for many years, and projects have been benefiting from it with huge amounts of free compute for years, but now the free money has run out.

danpalmer• 6 years ago

TravisCI bought goodwill and marketing of their paid offering by offering free builds for open source products.

Effectively removing or severely restricting that benefit will essentially lose the goodwill and word of mouth marketing.

It's true that to criticise someone giving you something for free is being a "choosing beggar", but that's not really what's happening here. TravisCI has bought something with their free offering, so it's fair that they lose that when they revoke that offering.

zwilliamson• 6 years ago

I moved my open source repos to GitHub Actions from TravisCI after experiencing 6+ hour build queues. So far, GitHub Actions has been great and I love the Super Linter!

bluedino• 6 years ago

It sucks when people start charging for stuff.

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

Related Stories