Travis CI is no longer providing CI minutes for open source projects
I guess it was inevitable https://news.ycombinator.com/item?id=19219216
https://twitter.com/james_hilliard/status/133608177669184307...
Hello James,
Thanks for writing in.
At the moment, credit allocation for OSS projects is on hold as per directives from management. Sincere apologies please.
We will provide updates once we get additional approval from management.
Thanks for your patience
-- MK
Your Friends @Travis CI
Test and Deploy with Confidence.
192 comments
[ 3.7 ms ] story [ 217 ms ] threadhttps://news.ycombinator.com/item?id=18978251
But with Travis and Idera it was pretty clear it will go this way, looking at past Idera purchases.
Good thing I was an earlier GitHub Actions adopter because now I don’t have to do as much work.
And I think they're missing the gravity of the situation—there were (and are still) a _ton_ of OSS projects out there that are configured to use Travis CI for their testing and build pipelines, and it's not free to switch to something else (even though there are many adequate alternatives).
I wish there was another way, like providing a meager amount of build minutes, or just reducing the OSS builds to run on a few dozen servers, even if that means days-long build queues. That's better than just ending service abruptly like they did.
I wrote [1] about my own plans, but I know many devs (especially for tiny side projects) just don't have the time to update them to something else, and we're likely to see a number of smaller projects kind of fall into disrepair from this.
[1] https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricin...
The license terms changed and boom now you're out of service.
If such OSS projects were running on Gitlab (either gitlab.com or selfhosted) then any of the members could have donated spare computing resources by running a gitlab runner on their prem.
Many people have PCs running 24/7 and could spare a vm to lend to their favourite projects.
The magic of Travis was that with a couple clicks of OAuth you were signed up and running builds for your own PRs. My first thought upon seeing this years ago was “How many people are using this to mine crypto?!“.
It's a bit more complicated than that.
I run gitlab and gitlab runners for a living, I can tell.
First thing first, you'd have to register a runner with a specific project. So no "arbitrary code".
Second thing, unless you can push a branch to the project main repository, no pipeline is ran. So for your own personal forks you'd either rely on gitlab.com-provided free minutes or you run your own runner (and tbh, it's fairly easy).
Last thing: you should not think of regular end-users. Think of middle to advanced users, that have a home server or something like that (homelabbers?).
This isn't what "arbitrary code" means.
Having worked at a Travis CI competitor that also offered open-source credits. The answer is "many" if you don't do anything about it...
With GitHub Actions it's even simpler, and no OAuth required at all.
I especially like the auto-suggested template-types based on what kind of project the repo hosts (Node, Python, etc).
For those who don't know, we have a GitLab for Open Source program which gives our top tiers and 50K CI minutes/month for free to OSS projects: https://about.gitlab.com/solutions/open-source/
Hope this helps!
The nice thing about Gitlab is that you can mix on-prem and saas according to your need.
For example I am now running my own gitlab instance at home but I'm thinking of switching to the gitlab.com offering while keeping runners at home. By pairing gitlab with Hashicorp Vault I could keep encrypted stuff in my repo and decrypt them when they are checked out on the (local on-prem) runner.
Super cool, so much flexibility!
Since then I have switched a bunch of projects over to Github Actions, fortunately they were all relatively simple enough to make that straightforward.
[1] https://news.ycombinator.com/item?id=25003387
OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality. This has happened, in various forms, to most 'free as in beer' services given enough time. Companies typically provide the service as some combination of crush the competition / building goodwill / altruism / the prospect of eventual conversion of some small fraction of OSS projects to a paid version. The reasons tend to vary (in this case, new ownership) but eventually the bottom line tends to win out. Often you won't be given much time to transition when the free ride ends.
I don't think that's the issue. Large parts of Travis are open sourc, but no one uses it because they are too complex to set up; and there are better self-hosted solutions than Travis.
Travis was attractive, because it was free hosting, not just software. And worked with just a few clicks
It's certainly easy to get into these lassaiz-faire ad-hoc remote free solutions, it's harder to maintain your own CI, but if quality and consistency is important, it's not that hard.
It doesn't actually matter much for this if you use an OSS CI service like Gitlab: the hosted service is still dependent on the generosity/marketing of the company hosting it, and switching to self-hosting is much more effort than porting config from one CI service to another.
https://docs.gitlab.com/ee/user/project/import/gitlab_com.ht...
hosting CI yourself is equally simple. The worker can be installed with few commands, and with a few extra you can configure autoscalling:
https://docs.gitlab.com/runner/install/
I had heard of CI testing, and sure it sounded good, but we had all been making due without it, and I didn't have time (and certainly the projects didn't have money) to set it up. But travis made it so damn easy and free to turn on, there was no reason not to try it. Once tried, there was no going back, we would never want to do otherwise.
Travis really defined this market and opened up CI testing to entire communities. We owe them (employees, former management) a debt of gratitude for that.
But then we come to depend upon it for sure. Which they had no obligation to supply it forever, and perhaps it wasn't even sustainable business to do so. So now what? Well, now we move over to other free options like Github Actions which fortunately exist.
But is it dangerous to depend on the largesse of for-profit companies? FOR SURE.
Is it, at this point, hard to figure out how to do otherwise? FOR SURE.
So, what could we do instead? In my dream world, we'd have a non-profit collaborative project to provide CI to open source on an ability-to-pay basis. Is that likely? I dunno, raising money for open source is already a problem. And it's a hard project. As long as there are companies providing it to us for free, it's definitely less likely.
You might hope you'd get a broader pool of companies paying in to the fund, so you're less dependent on any one company. But unless the donors throw almost infinite money at you, you would soon need to make some kind of restrictions on which projects can benefit and how much they can use per month.
The best I can think of to do is to make your CI config a relatively simple wrapper around generic tools, so it's easy to move when you need to. This is often a trade-off with things like parallelism and caching, but at least if you know it's a trade-off you can make sensible decisions.
There's obviously a cost associated with this, but after started reading this thread, I just ported 10+ of my GitHub project from Travis-CI to GitHub Actions.
Unless your project has very specific/weird build requirements (in which case it should not be part of .travis.yml, but in a separate, reusable build-script), it was really surprisingly simple to make the switch.
I've ported Emacs, NodeJS and Python projects with ease. Having had many of my project built using makefiles, running that makefile somewhere else was no big deal at all.
If anything, if making the switch now is hard work, you should use that effort into making your build more portable. You may thank yourselves 5-10 years down the road when this same thing surely is bound to happen again :)
Github Actions is free. I migrated some repos to Github Actions this year and the process is relatively painless.
Also I do not expect Microsoft to turn off Github Actions for OSS projects as long as you stay within your rate limited budget.
Their home page at travis-ci.com still says:
> Testing your open source projects is always 100% free!
> Seriously. Always. We like to think of it as our way of giving back to a community that gives us so much as well.
That is simply not what's going on. As far as anyone can tell, they are offering some OSS which meet specific criteria (including no company funds any part of it, including paying people to work on it(?!)) free minutes in fixed monthly allotments, which you have to keep asking for every month. And there are only so many total minutes they are willing to give out, which apparently have now been frozen.
How can they have written a letter only two weeks ago saying "Open source accounts, as always, will be completely free under travis-ci.com"? How can their home page still say "Testing your open source projects is always 100% free!"??
At this point, it is hard to explain it as anything other than intentional manipulative dishonesty.
I don't understand why they don't just say "Yes, we can no longer provide free open source accounts." They aren't actually fooling anyone, I mean people notice that they don't have free accounts anymore, right? It is a weird attempt at some kind of reality distortion.
I guess you could try replying: "Credit allocation"? I don't understand, Paul Gordon wrote on Nov 24 "Open source accounts, as always, will be completely free under travis-ci.com." Is this not true?
I'm kinda curious what they'd say, but I guess it's just torturing poor support staff whose jobs probably aren't going to last either.
JetBrains open source licenses have a similar restriction https://www.jetbrains.com/opensource/
> Your project is NOT sponsored by a commercial company or organization and does NOT have paid employees
> Your project does NOT provide commercial services (such as consulting or training) around the software, and does NOT distribute paid versions of the software
I don't think I have ever worked on any where there wasn't a single person writing code while getting paid by their employer. Is that enough to disqualify you from JetBrains criteria, do you think?
In email from travis support it was expressed as:
> Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)
To me, that seems to say if someone commits code while on the clock, that is employees paid to work on the project.
That definitely disqualifies a huge number of open source projects, probably the majority, right?
We then realised we didn't need the license, as the community edition has everything we need.
But to move to one of the licensing models on their pricing page requires us to start to pay per-user. How many seats should we buy? I have no idea. Right now, if someone who's given one or two drive-by patches wants their own space on the project, we just give it to them. If it cost us an extra $50/year (or $240/year or $1200/year depending on our tier) for such users, what's the cut-off for who gets to be part of the project? It just changes the whole calculus.
I don't use jetbrains, it was brought up by analogy with travis. In Travis case, whether it's a "bad thing" or not, I think it's a dishonest thing to be claiming you provide "free service to open source projects" while introducing criteria that would exclude the majority of open source projects — which you also used to include but have switched to exclude while claiming you're doing the same as ever.
So it's clearly their perogative to set whatever criteria they like, it may or not be a "bad thing", but it is definitely a huge change from what they used to, and is only actually giving free service to a very small slice of open source projects, while publicly wanting to take credit for doing otherwise.
> Your project does NOT provide commercial services (such as consulting or training) around the software, and does NOT distribute paid versions of the software
Jetbrains should really take it to the next level and require all developers on your open source project to provide up-to-date proof of unemployment benefits.
Projects which have a sponsoring company or consulting/training/paid-tier income around them can afford to pay that.
> A Personal license is an option for private individuals who purchase a license with their own funds, and solely for their own use. Personal licenses are not to be purchased, refunded or in any way financed by companies.
https://sales.jetbrains.com/hc/en-gb/articles/207241075-What...
I think it is more likely that there is intense internal conflict around this decision, and some people may be openly reaffirming their beliefs in the mission of TravisCI.
I think the far more likely explanation is that updating the websites was very low on the priority list of the people who made this decision.
0. https://blog.travis-ci.com/oss-announcement
it is dishonesty at best
For example, a school could use its endowment to give out scholarships, a pension fund pays out retirees, etc etc.
During the financial crisis we saw that in finance, they do good by making their principals money. The investors can go F themselves if they're in the way.
Executives became dynastically rich by bankrupting their companies.
The heads of Lehman Brothers and AIG Financial Products, Dick Fuld and John Cassano are classic examples.
It's even worse: VC "burn money" is way too often actively destroying and undercutting existing businesses in the guise of "disruption", and then once the competition is dead, prices rise to way higher than they ever were before.
Cases in point: Uber (destroying local taxis and then milking the customers dry with "surge fees"), AirBnB (literally "disrupting" all the neighbors around the illegal hotels), Facebook/Twitter (which competed with sustainable, moderated alternatives and now "disrupt" entire elections by allowing propaganda and lies unchecked), Doordash/Grubhub/whatever, they're all bad by actively MITMing and otherwise extorting restaurants, Yelp (again, extorting small businesses), Amazon (even though they're not using VC money, they're still burning down physical stores).
A single, open source, interface app needs to exist for co-coordinating 'radio cabs' and it needs to work for _all_ cities. Ubur/Lyft are somewhat close, but that market platform and co-ordination would never have happened without them.
Hotels / housing are an issue because of predatory monetary practices. As a society (at least in the US) we don't have planned community retirement, so anything expensive becomes a defacto investment vehicle. This leads to a preference for any policy that inflates the cost of housing, which directly leads to NIMBY and combines with anti-sprawl measures to constrain supply. At that point basic econ101 applies and prices just keep going up without ever correcting (anywhere jobs exist).
Social media and the other MITM attacks are probably symptoms of the same issue; yet I'm not quite sure what a true root cause and solution are. It might require personal AI secretaries or something similar that are interest aligned with the individual users, rather than any corporation or government. (To facilitate schedule arrangements that are optimal.)
It is always a question: is this "disruption" worth the cost - minorities and the poor cut off from taxis, illegal hotel operations robbing people (again, in many cases poor and working class) of their sleep, and trust in democracy as a whole?
^^^ The correct short version of my statement above.
Though it hurts the current businesses, the high prices won't last long. New competitors will see the chance in same services with lower prices and they'll go in. The problem is actually regulation and lobbying, which making new players harder to emerge.
Regulation in many cases, especially in those I mentioned, makes sense:
- Taxis should not be allowed to discriminate for anything, especially not skin color. Also, at least in Germany the fares are regulated to ensure people are not ripped off in "hot times".
- Hotels, and most AirBnBs are de facto hotels, are regulated to prevent issues with fire safety, theft, privacy, noise complaints (it's illegal to build hotels in residential zones for a reason) and many others.
- Something like Grubhub putting their own intercepting phone number in Google results via shady SEO tactics and charging people for any call is just ripe for abuse by competitors, additionally it's extremely unfair.
However there are some regulation that are made for the sole purpose of defending the existing players and keeping new players from coming into the market.
Some licenses have requirements like that, such as requiring some documents or certification before operating, meanwhile the existing players may not have them.
In any case, the failure starts with an unsustainable business model. Travis CI management set up a business that ultimately failed to the point where they needed to be rescued by a PE firm. If you want to complain, complain to Travis CI management. They're the ones who failed you. The alternative to the PE buyout was not Travis CI continuing as it had always been. It was Travis CI closing shop.
(I don't really know the details of the Travis buyout. Maybe there are other factors at play. In just giving a perspective on how these things often work. )
For something easily switchable like your favorite retail shop you can - and should if you don't want the collapse to hasten - continue as before, but for something your business depends on like CI it's a huge red flag that you should switch to a different supplier.
Is it worse than company collapsing though?
With that, you might not even have a warning sign.
Seems like it’s a damned if you do, damned if you don’t scenario.
https://webcache.googleusercontent.com/search?q=cache:zDTt0E...
It's possible that the CI market is just too competitive today and that resources allocated to Travis CI, including developer time, would be better spent elsewhere.
https://www.investopedia.com/terms/p/promissory_estoppel.asp
When I started an organization which was taken over in a rather hostile way, I was very careful to make a bunch of legally-binding promises before the takeover happened, to help prevent it from becoming too evil.
I'm glad you had the presence of mind to do this and I'd be interested to hear your hostile takeover story. Thanks in advance.
Traditionally, the purpose of autobiography is to tell all of these stories.
I've got enough potential liability piled up there that I think some of these stories will only come out once I'm good and dead. Not just legal liability -- although I did sign an NDA/non-disparage -- bringing up dirt from past businesses is like mudwrestling with a pig: everyone ends up looking dirty.
In this case, I'm glad to say I acted with complete integrity at every point, but knowing the parties involved, we'd end up in a cesspool of rumors and falsehoods, and no one would come out looking clean.
Live. Learn. Move onto the next business. Give advice in generics. Some people will believe you, and others won't.
Pay a one time fee and get unlimited minutes forever, that would likely be binding.
But in this case, recipients of the freebie didn't have to offer anything to Travis in exchange.
Would or wouldn't you'll never know, looking at you HP, ink for life =?> ya right
https://www.theregister.com/2020/11/12/hp_free_printing/
> Another requirement further qualifies the required detriment component; the promisee must have suffered an actual substantial detriment in the form of an economic loss that results from the promisor failing to deliver on his or her promise. Finally, promissory estoppel is usually only granted if a court determines that enforcing the promise is essentially the only means by which injustice to the promisee can be rectified.
The open source project would not suffer an economic loss by not using Travis. They would be free to stop using Travis or go to another competitor providing a free plan.
Exceptions to the above I can think of:
* Travis didn't charge them, then started charging them despite the promise
* they suffer an unrelated economic loss because they stop using CI
* they're forced to hire someone to convert them to another CI system (economic loss in form of wages, money to operate their own CI), though the loss would have t obe substantial (is that relative? e.g. in case of a low budget, is even a small sum substantial?)
1) Travis achieved a market-dominant position in part thanks to widespread use by open source projects.
2) Open source projects invested significant resources into integrating with Travis based on their promise.
3) Moving to something else would take significant resources. The exact loses are probably exactly how much it would cost to pay to continue to use Travis (and collecting some of that money is precisely why Travis stopped offering a free service). If it wasn't significant, Travis wouldn't have made the change.
That doesn't mean it's worth anyone's time to litigate.
As a footnote, the traditional way to handle something like this is to continue to provide a free service, but to make it worse and worse and worse. Travis could satisfice the promise by keeping an insecure Raspberry Pi under someone's desk running old code as the "server farm" for open source. Courts don't necessarily consider satisificing to be following through on a promise, but costs of litigation go way up when there are open legal questions like that. At that point, it's usually almost definitely not worth anyone's time to litigate.
I think many would agree that moto has been broken several times over the years.
It's a shame. Something like this should exist, but I can't blame them for not wanting to do it for free.
With Github Actions on the scene now, I don't see much reason to use Travis over one of the alternatives.
And it seems they maintain their own apt mirror or whatever, the package install speed looks unreasonably fast.
But they currently only give 250 minute (default config) per week to free account now, probably due to the runner cost.
They give you 10,000 minutes of build time on their 2cpu/4gb workers per week with a max of 4 concurrent workers.
Edit: Looks like you get 4 concurrent jobs if you register as an open source project.
My biggest complaint has been it lacks an very useful built in ability that Travis had, which is automatically running your builds on the merge of your current branch and target branch. You can right a script to do it yourself, but there missing some environmental variables to do it easily (because the build can start before the target branch is known).
I've also hacked about the 'merge' problem but it's not entirely satisfying.
That all said, with GH actions currently being entirely free, and doing PRs better than CircleCI, we might shift our focus there.
https://travis-ci.community/t/current-known-issues-please-re...
https://github.com/travis-ci/travis-build/pull/1719
1) If you can cause it to be run on arbitrary code then you can cause it to reveal the secret. Even if the only output you see is a pass or fail. 2) If you can't cause it to be run on arbitrary code, then why do you need to see any output?
Filtering secrets from logs only protects accidentally dumping your environment to a log Because you left in an echo $SECRET. It doesn’t stop a determined attacker who can run arbitrary code.
? 2018: Travis CI announces they are starting the process of merging travis-ci.org, which provided free builds for OSS projects, into travis-ci.com, which until then was only for paying customers. They promise OSS builds will continue to be free.
? 2020: Travis CI announces they are shutting down travis-ci.org at the end of the year and all projects have to move to travis-ci.com. They promise OSS builds will continue to be free.
Early November 2020: travis-ci.com switches from providing unlimited builds for OSS to only providing 10k one-time credits by default. Projects that meet certain guidelines (e.g. no one paid to work on them) can apply for recurring credits.
Later in November 2020: CI for many OSS projects that had migrated to travis-ci.com starts to fail, as they've exhausted their 10K credits.
Dec 2020: If what is reported here is accurate, Travis CI stop providing any recurring OSS credits. CI breaks for the remaining OSS projects on travis-ci.com.
Jan 2021: travis-ci.org shuts down. CI will be broken for all projects using it. They'll have the option of migrating to travis-ci.com, but will soon break again as they exhaust their 10k credits.
I suspect that many, many projects haven't migrated from .org to .com and are going to be surprised when their CI breaks on January 1st. It looks like their only option is to start paying Travis CI or move to an alternate provider (like CircleCI or Github Actions, both of which have free tiers for OSS).
If Travis CI's new owners are no longer willing to provide free CI services to OSS projects, that's understandable. I just wish they'd communicate that clearly in ways that their users won't miss.
(BTW, if anyone from Travis CI is reading this, I reached out to your support team last week for help on a problem that is blocking us from potentially paying you. I haven't gotten an answer yet on ticket 23831. Any help is appreciated.)
I suppose I need to look for alternatives – although I hate doing these kind of "plumbing" things; I'd rather be working on more useful code.
So "my friends" at travis ci just disabled my free access to travis ci for my open source projects and I am suppose to have confidence. nice!
http://www.oilshell.org/blog/2020/11/fixes-and-updates.html#...
A contributor added .travis.yml about 3 years ago, before I had ever used it. But I've been around the block enough to know that getting stuff for free is temporary. (And to be fair, I did like Travis CI free service a lot better than I thought I would.)
So when I needed to enhance the continuous build back in January, I did it with a PORTABLE SHELL SCRIPT, NOT with yaml. Both Travis CI and sr.ht provide Linux VMs, which are easily operated with a shell script.
The script called "Toil" does the following:
1. Configures which steps are run in which build tasks (both Travis CI and sr.ht can run multiple tasks in parallel for each commit)
2. Logs each step, times it, summarizes failure/success
3. Archives/compresses the logs
3. Publishes the result to my own domain, which is A LOT FASTER than the Travis CI dashboard. (sr.ht is very fast too; it has a great web design.)
This ended up working great, so I have multiple CI services running the same jobs, and publishing to the same place: http://travis-ci.oilshell.org/
(I plan to create srht.oilshell.org for security reasons; it isn't ideal that both services have a key to publish to the same domain.)
----
I think this is the future of the Oil project: shell scripts to enable portability across clouds. If you want to be fancy, it's a distributed or decentralized shell.
This is natural because shell already coordinates processes on a single machine.
- A distributed shell coordinates processes across multiple machines (under the same domain of trust)
- A decentralized one does so across domains of trust (across clouds)
-----
Really great work in this direction is gg:
https://buttondown.email/nelhage/archive/papers-i-love-gg/ comments: https://lobste.rs/s/virbxa/papers_i_love_gg
which is a tool that runs distributed programs across multiple FaaS providers like Amazon Lambda, Google Cloud Functions, etc.
https://github.com/StanfordSNR/gg
My "toil" script is a lot more basic, but an analogous idea. I would like to create a slightly tighter but improved abstraction that runs on multiple cloud services. Notes on gg here:
https://github.com/oilshell/oil/wiki/Distributed-Shell
If anyone wants to help, get in touch! If you are pissed off about Travis then you might want this :) I think these kinds of multi-cloud setups are inevitable given the incentives and resources of each party, and they already exist (probably in a pretty ugly/fragile form).
The problem is, if you assume good will from Travis, then this is a VERY drastic action to take since it strongly contradicts their past statements. From that you would infer, Travis is in serious trouble and I would worry a lot about building in dependencies on it as a paying customer.
On the other hand, if you assume bad will from Travis .... well, then that also would mean you should not use them as a paying customer.
So it's just bad.
On top of that it is easy to setup a private CI runner on a $5 month VM.
https://about.gitlab.com/solutions/open-source/
A list of fellow OSS projects can be found at https://about.gitlab.com/solutions/open-source/projects/
...maybe they're not doing so well financially and you should start looking at a Sam's Club membership instead of renewing, because this hypothetical Costco might not be around for a full year's membership.
[1] https://blog.travis-ci.com/2019-11-12-multi-cpu-architecture...
I emailed them last week; I suspect I'll receive a similar email, soon!
It should be possible to make a GitHub action that runs an existing .travis.yml.
https://github.com/marketplace/actions/run-travis-yml
The action executes the stage scripts making that part portable at first. It helps a lot migrating as not everything needs to be rewritten at once while already reducing the build-times on Travis.
Language handling is a different beast, but I had the same thought that with some Ruby know-how a port of the travis-build as a whole could be done.
If not even running locally.
Bamboo. ... TeamCity. ... Appveyor. ... Codeship.
lots more use google
https://github.com/SophistSolutions/Stroika/actions?query=br...
People are now moving to github actions, which are fine, but for how long github actions are going to be free for OSS projects as well? One cannot expect all these freebees to last forever, that's why open source needs financing like any other software development.
I don't know ... cause ending travis free CI is going to like... disrupt an entire ecosystem of OSS projects. Every single maintainer doesn't have the time to learn and set up github actions... Isn't that obvious?
I predict that will eventually end too as they aim towards profitability.
Really it’s marketing spend for them to establish themselves as OSS-friendly. Nadella is just getting a lot more for the money than Ballmer did.
(MS employee, not anything related to this though).
Honestly, I don't really think so. I think MS's goal for GitHub is to be a "loss leader" to keep developer mindshare. They lost a lot of developer mindshare to linux, open source, etc. in the migration to the web and cloud.
Providing GitHub and CI for free to open source/students is a great way to keep developer mindshare. Make sure it's nicely integrate into Azure cloud for deployment and devops and you have a streamlined pipeline of leading large numbers of developers to your cloud platform.
There's also Github Actions and Bitbucket Pipelines which I think are very similar in style, and also have free tiers.
There's also the "Raspberry PI in a closet" option, which I might explore over the Christmas holidays.
Dockerhub being free is something else I can't see lasting forever, their bandwidth costs must be immense? Although maybe they make enough from enterprise contracts to make up for it?
And yes, paid accounts are exempt. But the costs are catching up.