Travis CI is no longer providing CI minutes for open source projects | Hacker News Reader

Travis CI is no longer providing CI minutes for open source projects

523 pointsjameshilliard187 comments

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.

View on HN

Only a few weeks ago they wrote a letter (https://blog.travis-ci.com/oss-announcement) that said "Open source accounts, as always, will be completely free under travis-ci.com."

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.

I wonder how many people start out making pledges like that because they wish other companies would and they want to be the change they wish to see in the world. And they don’t realize that taking investor money means you no longer have the power to keep your promises even if you want to because you’re promising with other people’s money.

Part of the reason to make promises is that they are legally enforceable:

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.

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

I'd love to hear that story as well, and the nature of the legally binding promises you managed to make.

It's probably too soon. Over the course of my career, I've encountered a significant number of really juicy stories that I tend not to explain, as there's a lot to lose and not very much to gain.

Traditionally, the purpose of autobiography is to tell all of these stories.

This is exactly the case.

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.

My philosophy exactly. The phrase wrestling with a pig in the muck comes to mind....

I don't think a promise to offer something free forever is necessarily binding unless there is consideration from the other party.

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.

> Pay a one time fee and get unlimited minutes forever, that would likely be binding.

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/

I'm sure there will be some ensuing legal battles over that one.

IANAL, but I don't think that would be applicable in this case:

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

IANAL either, but I think, if someone were to take it to court, it would:

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.

Please share more info about your case

My previous company was on Travis, and as soon as I saw that Travis was purchased by private equity, I knew the downward spiral had begun and I recommended we move to something else. Not surprised that this is happening a couple of years later...my understanding is that private equity will tend towards slowing/stopping development after acquisition to cut costs/headcount, and then squeeze the remaining value from what's left, so this is in-line with that playbook.

Are there any evidence of private equity providing benefits for society? Sometimes it looks like they have a inverse Midas hand, everything they touch putrefy.

There's this meme that private equity companies are vultures circling overhead looking for prey, and when they find a poor innocent victim they swoop in and destroy it. I worked at a PE firm in the past, and my understanding was that the companies we bought were all looking for buyers because they were already failing. So a company that would otherwise have to close looks to the PE markets for help. The PE firms say, ok - we'll buy you out and then we'll require you to change your business so that you become profitable. The stated goal was to buy a struggling business, fix it up, and then sell it a few years later. Didn't always work, obviously.

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

Doesn't change the fact that being bought by a PE firm is a very bad sign for customers of the business.

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.

> Doesn't change the fact that being bought by a PE firm is a very bad sign for customers of the business.

Is it worse than company collapsing though?

With that, you might not even have a warning sign.

Well, a collapse gives you certainty.

And how often are companies castigated on here for getting acqui-hired and shutting down?

Seems like it’s a damned if you do, damned if you don’t scenario.

Agreed. When a service gets bought by a PE firm it's a bad sign. It's not the cause of trouble but a sure symptom.

You're getting the cause and effect backwards. Private equity generally buys companies that are already in rough shape and tries to turn them into something profitable (which often means a lot of cost cutting). That's an important part of the ecosystem. If anyone's harming society it's the VC ecosystem that gets companies hooked on free money and encourages them to burn it as fast as possible, blocking sustainable businesses from playing in that space.

> If anyone's harming society it's the VC ecosystem that gets companies hooked on free money and encourages them to burn it as fast as possible, blocking sustainable businesses from playing in that space.

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

> and then once the competition is dead, prices rise to way higher than they ever were before

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.

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

I don't mean those kinds of regulation, some regulation are definitely needed for the better.

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.

At the same time some of those market disruptions need to happen and the incumbents were probably never going to get there.

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

> At the same time some of those market disruptions need to happen and the incumbents were probably never going to get there.

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?

Disruption was necessary, these markets were already broken. The (current disruptions) listed (in what I replied to) weren't the correct form of disruption.

^^^ The correct short version of my statement above.

The PE firm that had a take in a company I worked for wasn't hostile. They held a pretty long term stake too from what I know about the history of the business.

I am not sure if it counts as providing a benefit to society but I think the Dell private equity process(taken private in 2013 and reintroduced to the public market in 2018) is generally considered a success from a business standpoint. As mentioned in sibling comments, a lot of private equity investments are an attempt to do something similar.

Like a lot of private equity takeovers, Dell is now riddled with debt and having issues with debt load

https://webcache.googleusercontent.com/search?q=cache:zDTt0E...

In the old days they provided growth equity to businesses that generally wouldn't have access to that capital. Now I'd say your observations are pretty much accurate.

https://www.youtube.com/watch?v=62kxPyNZF3Q

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.

Like everything else in finance, they do good by making their investors money. These investors then can use the money for fulfilling their purpose/charter/business plan.

For example, a school could use its endowment to give out scholarships, a pension fund pays out retirees, etc etc.

I would challenge the conceit that 'they do good by making their investors money.' They make their investors money, full-stop. Perhaps their investors choose to do good with that money, more likely, they choose to do business with that money. The private equity at no point ever did good through the act of making money, they did their job.

I think the thing here is that anyone can do good while making money- for instance, the longer-term PE groups mentioned around this thread that have respect from the companies they now own, or the factories that make sure that their employees are safe, paid well, and allow a work/life balance, or the finance companies that donate to charities and the like. The issue is that when money becomes the primary motivator for getting out of bed in the morning- and ethos and pathos get thrown out of the window entirely- you get companies who don't care about their employee's well-being or who don't care about the people on the other end of the line.

> Like everything else in finance, they do good by making their investors money.

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.

Like all the apps you are using now ;) haha, whoops.

my state run pension invests in private equity funds to diversify the portfolio

It's absolutely childish to make promises you can't keep. Like Google and don't be evil.

It's no excuse not to be honest though. Just say "we made a promise that we won't be able to keep anymore, sorry".

Google - "Don't Be Evil"

I think many would agree that moto has been broken several times over the years.

"including no company funds any part of it, including paying people to work on it(?!)"

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 have worked on many many open source projects.

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?

I agree. Any open source project that's reasonably widely used is going to have some team from some commercial company submit a PR to fix some issue they're having at some point.

Why would this be a bad thing? Jetbrains is not a charity, and their free open source license is in order to support people who can't otherwise pay for a license, not to make another company's balance sheet look better on their dime.

They (neither jetbrains nor travis) don't need to give anything to anyone, true, so I don't know if it's a "bad thing" if they decide to give free things to some but not others.

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.

We were denied a renewal of JetBrains' software because we pay several people to work on our open source software.

We then realised we didn't need the license, as the community edition has everything we need.

Our project is definitely open-source, but has an LF sub-project with a pretty decent amount of funding. We've been playing with the gitlab functionality, and was thinking it would be good to support a fellow open-source project financially, since we can.

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.

If a company pays you to help maintain X then you can't use JetBrains but if your company lets you work on open source software, but not anything specific, during work hours then maybe you can still use it?

> 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

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.

I think you’re misunderstanding - you can have a job just the project you use JetBrains products for can’t be your job or anyone’s job.

FYI, you're replying to sarcasm.

Seriously. Better better be careful about whose pull requests you accept.

For what it's worth their flagship IntelliJ is, for personal use, only ~23€ a month, and phpStorm ~9€ a month.

Projects which have a sponsoring company or consulting/training/paid-tier income around them can afford to pay that.

The personal use license can't be paid for by your employer though. (Though if a company is paying you for the OSS work, you can probably afford a personal license)

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

>intentional manipulative dishonesty

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.

What mission? It's a CI/CD platform.

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.

It wasn't just a "website update", it was also a blog post by Paul Gordon, their Product Marketing Manager, about their enduring OSS support. Also, he outlines part of their mission in the post, if you're curious.

0. https://blog.travis-ci.com/oss-announcement

any proof on your claim?

it is dishonesty at best

Many people are saying to those of us who _haven't_, for one reason or another, gotten completely off of Travis CI, "the writing was on the wall" or "you can't expect free forever."

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

Because people absolutely refuse to learn from history. The gravity of the situation is the same as it always is: OSS projects have created a hard dependency on a commercial 3rd party service because it was given to them for free. Free service is now going away and they're screwed because they have no plan 'B'. The issue isn't that they haven't gotten off of it already, it's that they likely never should have gotten on it to begin with. Seriously, with all the OSS projects building workflows on Travis CI / Slack / GitHub (I'm talking about the non-git parts of it like issue management) / etc how do they think this will all end? Even YouTube is sending signals that the free ride (for unmonetizable content) will likely end.

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.

What was the better option? Should small OSS projects have lived without CI for the last few years? Or should everyone who publishes an OSS project set up and maintain a self-hosted CI service for it? Either option would be a massive drag on OSS development.

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.

So, my experience as an OSS developer is indeed that I wouldn't have switched to CI in the first place if Travis hadn't existed.

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.

If there was some big central fund to pay for CI for many open source projects, it would probably be for-profit companies donating much of the money to support that. Is that much different to for-profit companies making in-kind donations of free build time?

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.

Yes, I think it is much different.

migrating GitLab from "cloud" to self-hosted is as easy as importing the project. You can even import in batch and things will "just work".

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'm talking about setting up the infrastructure before you get to either of those points. I don't want CI running on my laptop - especially for an open project where anyone can submit a merge request - and I don't have a server to use for it, let alone a private Gitlab instance ready to import projects to.

Use containers for CI, run local, do merges on maintainers machine. Push to master once local CI passes.

> OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality.

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

If it's not selfhosted, or it's not FOSS, it's not under your control and can go away any time.

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.

I honestly think this is the price that people pay for using proprietary software.

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.

Running arbitrary code on a distributed network of end user PCs with network access is a recipe for a bot net. Yes it’s doable but it’s not a magic wand to claim that an open platform will solve it.

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?!“.

> My first thought upon seeing this years ago was “How many people are using this to mine crypto?!“.

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

What is the state of the art in doing something about this? Has anyone tried using CPU perf counters to see if the workload looks like hashing?

Indeed, that is why Travis said they were changing the way they handled open source, because people were using it to mine crypto. They just weren't clear that the "change" was basically "not anymore providing free services to open source".

> Running arbitrary code on a distributed network of end user PCs

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

> First thing first, you'd have to register a runner with a specific project. So no "arbitrary code".

This isn't what "arbitrary code" means.

> The magic of Travis was that with a couple clicks of OAuth you were signed up and running builds for your own PRs.

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

Saw the note about GitLab (I work there) and thought I'd chime in.

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!

Thanks for chiming in! I like gitlab so much I couldn't miss this opportunity to recommend it.

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!

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

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

I help out as a maintainer for an open source machine learning group, and first learned about the switch in Travis CI's policy from your blog. Not too long after, the projects the groups repository owns all got switched over to Github Actions. I know that especially for folks that have many smaller projects, there's a lot of overhead in switching, but I really did appreciate your alerting people to the upcoming change through a different venue, as I'm sure it saved us some pain.

Ah, Jeff, actually thanks to your post I saw that most of the projects I contribute to had Travis CI builds take almost a day and I went over most of those that used free TravisCI/CircleCI/Semaphore and started migrating them all to Github Actions. So again, thank you for your particular inscription on the blog, I guess.

Another point: is there an open spec for GH Actions, that Gitlab could implement? Or vice versa, could Github support Gitlab CI? I am thinking of CI these days as some kind of wild west as back in the days before a common Open Container Initiative spec...

I don't think something like this will happen, because GitHub Actions and GitLab CI work quite differently. But maybe there will be a migration tool from one to the other.

There’s Tekton?

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

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.

What "rate limited budget"? As far as I could tell there were no limits to Github Actions open source free?

You are correct and I was wrong. At the moment it applies to private repositories only.

When this was posted to HN a month ago [1] is actually when I learned it was going on -- I sure wouldn't have figured it out from travis' communications, even to this day. Up until my projects simply stopped building at all I guess.

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

Are there GitHub CI integrations that offer payment integration, so that the submitter of the pull request can be charged for the costs of CI related to their pull request?

what kind of project would you use this in? I can see how this might combat a very specific type of abuse, but it seems like it'd be even more effective in deterring contributions entirely.

Any project where I as project operator cannot afford CI credits for the hundreds of pull requests people submit to me while presuming I can afford to provide them CI.

GitHub actions are free for open source projects

I think the number of people that would choose to pay for a PR to your project is small enough that you could probably just do it manually, and ask them to venmo/paypal/cashapp you money. You are probably not going to get very many.

This may be a bit sudden. But instead of heaping scorn on them, I just feel grateful for the millions they must have invested in OSS. It's unlikely they are out to hurt anybody. I'd guess the vast majority of people there, now and in the past, would love to be able to continue doing so.

So, if anyone can come up with the name for whoever bought them, a sale that was probably done with little alternatives already, then hate those peoples with all you got, got ahead[1].

But don't take it out on the people that helped you all those years. Not even if they screwed up the endgame by, maybe, being too optimistic for a week too long.

[1]: But not too many death threats, maybe. Even just for purely selfish reasons, one wouldn't want commitments to OSS become a poison pill that makes any company providing such services toxic to investors.

The original Travis CI GmbH, a German company, company is what the OSS community should be thankful for. They’ve been literally running build needs for at least half of GitHub.

However; I don’t think anyone needs to be grateful for Idera Inc, an American company, which has done nothing so far but ruining Travis CI for the rest of the world but themselves.

Thankfully the world has organically moved on to things like GitHub actions, but this personally will impact me as I have many repos out there that get 1 contrib/year, which would use maybe 2-3 minutes/yr. Lesson of the story here: There’s nothing such as free, even if there is, it will not last forever.

> done nothing so far but ruining Travis CI for the rest of the world but themselves

Don't forget the private equity firm and it's employees have a job to do as well - provide good returns on investments. That doesn't just benefit the wealthy, but if you have a pension fund (state or private) you are probably benefiting from it as well.

> Lesson of the story here: There’s nothing such as free, even if there is, it will not last forever.

In this economy, sadly no.

> This may be a bit sudden. But instead of heaping scorn on them, I just feel grateful for the millions they must have invested in OSS. It's unlikely they are out to hurt anybody.

I think a lot of the scorn is directed at their lying to people's faces, rather than at their discontinuing their service. And I'm not talking about lying in the past ("3 years ago you promised me free CI forever") – I'm talking about lying right now, after the decision was made (as pointed out by others).

I'm also thankful to Travis for teaching me what CI is and make me set up CI for every new project instinctively; even if it's not always Travis anymore.

Without their free + painless service, I am not sure I would have got that reflex, as I couldn't afford it when I started programming; and I feel like they also created a culture where OSS contributors expect every project to have some kind of CI.

> But instead of heaping scorn on them, I just feel grateful for the millions they must have invested in OSS.

Agreed. They've done good stuff for OSS up until now, and they deserve credit for that. No need to feel bitter or entitled over something we've received 100% for free.

But despite that, Travis-CI is not serving my (or other's) OSS needs right now, and people are obviously looking for alternatives.

There's nothing wrong with that.

The situation with Travis CI is confusing, has not been communicated well by them, and is definitely not getting enough coverage for the amount of disruption it might cause. Here's what I've been able to piece together:

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

Confusing is indeed the best adjective here; I can't even easily see how many credits I have on my personal account (only for the organisation I manage, I can't find it anywher on my personal account), or how many credits a build costs; I figured it out by triggering a build and reloading the page with the credits. Besides, what's a "credit" anyway? The entire UI and communication is pretty chaotic.

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.

I've moved on back when Travis CI employees have started recommending to turn off secret filtering in Windows build logs as a workaround for a bug, then decided to turn the workaround into a fix, exposing secrets in the logs of all Windows builds.

https://travis-ci.community/t/current-known-issues-please-re...

https://github.com/travis-ci/travis-build/pull/1719

"Secret filtering" is buggy, broken, stupid, misleading, and just plain wrong anyway.

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?

Unexpected behavior caused by any bug could print the variable to the build log, there is no need for malicious code to end up with compromised secrets.

Malicious code could also print the ROT13, hex, base64, or even selectively fail tests so that every failure is a bit of entropy.

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.

Masking secrets is not meant to defend against malicious code, but mitigates a class of issues in the build system and the software you build that could lead to inadvertently leaking secrets.

If a feature protects against accidents, why should “but a determined attacker can work around it” stop one from using that feature?

The question is how long the free party at github actions will last. That must be a considerable drain for github's Microsoft internal budget.

I predict that will eventually end too as they aim towards profitability.

> I predict that will eventually end too as they aim towards profitability.

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.

AFAIK GitHub isn’t losing money. They have a ton of enterprise users and that’s where the big money is. I could be wrong since they don’t publish the numbers. I wish GitHub IPOd and remained independent. Not a huge fan of Trillion dollar corps gulping everything that threatens them.

Think of it more as part of a suite and it makes sense: host your code on GitHub, use actions to deploy them, and deploy them to Azure. Make up money on 2 from 1 and 3. Google cloudbuild has a free tier too. Looks like AWS Codebuild has a comparable free tier too (do people use that?)

(MS employee, not anything related to this though).

Don't forget that providing the service for free to open source projects brings in money as open source developers in their younger years (school, college, university) tend to be low on budget, but are likely to use something they already know when they start to work for companies later on in their career.

As linked above, the idea of new leadership starving OSS and simply supporting existing enterprise contracts was talked about extensively in the acquisition announcement thread:

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

Speaking from experience: they're not even managing to service paying customers well.

That seems to stem from the fact they killed off pretty much the entire engineering team after the acquisition (judging by tweets I remember reading shortly afterwards).

The Idera way, buy product, fire devs, offshore to feature factory.

I will never again doubt what "purchase by private equity" means again, it is clear.

It really depends on who is buying.

But with Travis and Idera it was pretty clear it will go this way, looking at past Idera purchases.

What exactly made you "doubt" this fact before now?

I thought maybe there were sometimes exceptions to the rule.

There are NEVER exceptions to this particular rule, at least not in tech.

Ouch.

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.

The build execution bits of Travis appear to be open source: https://github.com/travis-ci/travis-build https://github.com/travis-ci/worker

It should be possible to make a GitHub action that runs an existing .travis.yml.

It's already possible, albeit but not a full port:

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.

Are they trying to kill the product as fast as possible? Because waiting for a first-party solution before kicking 99% of your users out is the perfect way to do it, short of simply deleting their accounts.

Good thing I was an earlier GitHub Actions adopter because now I don’t have to do as much work.

If 99% of your users are not paying, then you have a problem. Travis cannot compete with Microsoft when it comes to deep pockets. I think it is too late to get regulators to reverse the GitHub acquisition..

Hah. You think GitHub Actions won't do the same in a few years once this has all quieted down? You have to be better than your competitors if you want to beat them. Until you DO beat them, that is.

I’ve got accustomed to free solutions coming and going. The key concept here is that I’ll be using a free product for a few more years, until a competitor comes along.

I long ago switched to CircleCI for all my builds-- it has free builds for both open source and private repositories with a simple (and comparatively inexpensive) pricing plan based on parallel builds with Windows, macOS and Linux build containers.

With Github Actions on the scene now, I don't see much reason to use Travis over one of the alternatives.

What's the benefit of circleci? I'm looking into switching from travis-ci.org to github actions, so far.

Speed, their main selling point. The default config uses a <del>8</del>2 core + 7.5g memory runner and capable to build simple projects in literal one minutes(includes deploy) after you push even without cache.

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.

For anyone curious, the details on their OSS offering are at https://circleci.com/docs/2.0/oss/

They give you 10,000 minutes of build time on their 2cpu/4gb workers per week with a max of 4 concurrent workers.

Free accounts on CircleCI only have access to 2 core runners and can't run multiple jobs in parallel. Most open source projects I have seen on Travis do matrix builds which will take much longer to finish due to this restriction.

Edit: Looks like you get 4 concurrent jobs if you register as an open source project.

We pay for CircleCI at $WORK and it’s pretty good. You get up to 40x concurrency in the “Pro” plans and I’m sure you could work whatever you need into enterprise.

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 can echo all of this - we also pay, we're very happy, the concurrency is nice (I believe they're bumping it to 80x soon - when my coworker asked "but what's the catch" I realised we pay by the CPU minute anyway so higher concurrency is a win for CircleCI -and- for US ;) ).

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.

On this note, I started a little project to convert Travis.yml workflows to GitHub Actions: https://akx.github.io/travis-to-github-actions/

Currently it deals with rudimentary Python and Node.js workflows, but contributions are naturally welcome.

Looks nice, thanks for sharing. For the part to execute the run-script I'm currently going with a github-action itself:

https://github.com/marketplace/actions/run-travis-yml

it's based on the original travis-build so that utils like "travis_retry" are still available.

each command in the asserted stages (e.g. before_install, install) directly breaks the build while the script runs through and gives the fail exit at the end (while showing the commands run and their result as on travis, asserted stages are with folding).

might be a good addition to the online converter.

the other parts of the workflow (vm setup, caches, services, matrix etc.) I find hard to port automatically. this needs much more insight and often is specific to the languages. and then it's "relatively easy".

but an automatic mapping from the many languages travis supported looks overwhelming.

perhaps better is to actually have the whole travis-build project as a github action (but I'm not fluent with ruby).

Travis CI was, to my knowledge, the only CI provider that let you test projects on IBM Power and Z. [1] Are there any alternatives?

[1] https://blog.travis-ci.com/2019-11-12-multi-cpu-architecture...

Yep, you're correct. This is causing some interesting conversations in those spaces now.

If it's open source you can approach Open Source Lab at OSU for CI on Z Series.

In response to the scorn in the comments. Free SAAS resources are like Costco samplers. Be grateful when they are handed out, and be prepared for them to be taken away. These things do cost money, and like drugs are given away to make you a customer – but there's no such thing as a free lunch.

Sure, but on the other hand when Costco claims they're always going to have free samples, then slashes the hours they serve free samples down to an hour a week, and then says you have to have a gold-star membership to have samples, and then cuts the samples down to plain, individual saltine crackers and tortilla chips, and then they start limiting them to one per family, all while proclaiming that they love offering free samples in all of their coupon books...

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

When they had the previous announcement I switched my open source projects to GitHub actions.

I get that some people will not want more GitHub but I figured given all the configuration is open and checked into your repo someone will eventually make an open source clone that can read the same configs .

I also really like the way build scripts can be referenced by url/id such that I can just reference existing scripts made by other people. Super nice!

> I also really like the way build scripts can be referenced by url/id such that I can just reference existing scripts made by other people. Super nice!

I'm not familiar with that feature, can you give a link to docs/example/more info?

See this example action, it just "uses" other scripts

https://github.com/samuelmeuli/action-electron-builder

docs

https://docs.github.com/en/free-pro-team@latest/actions/refe...

Thanks! Still not sure what you mean about https://github.com/samuelmeuli/action-electron-builder

I see the workflows at: https://github.com/samuelmeuli/action-electron-builder/blob/...

and

https://github.com/samuelmeuli/action-electron-builder/blob/...

What about them is using other scripts? Oh, do you jsut mean things like `uses: actions/setup-node@v1` is using that standard actions/setup-node "step"? Yeah, you can refrence steps defined elsewhere, ok, I get it!

For some reason I was thinking you meant something else. OK, thanks!

> Your Friends @Travis CI > Test and Deploy with Confidence.

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!

I switched to github actions. Works better than travis ci ever did. So far appears perfectly free for open source projects.

https://github.com/SophistSolutions/Stroika/actions?query=br...

Gitlab provides 400 minutes a month on their free plan and you can use that on private projects, not just OSS.

On top of that it is easy to setup a private CI runner on a $5 month VM.

Open source projects can also apply for our OSS program and get more CI minutes and features for free :)

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/

How many more minutes? The page you link to doesn't seem to have details.

I just got an OSS project wired up using TravisCI. And during that process, I noticed OSS builds had a backlog of 5000+ jobs. It took sometimes 45 minutes for my build to process.

It's a shame. Something like this should exist, but I can't blame them for not wanting to do it for free.

I don't as such blame them for not wanting to do it for free, but they did want to do it for free until they didn't, and you could argue they're under no obligation to keep doing so, but given the way they have introduced the change, I would be uncomfortable being a paying customer of theirs, too. What's to say they won't be trying to change the terms of their offering in other ways? And if so, why should I think they would get any better at doing so in a fashion that minimizes the disruption?

If CI builds were defined in a programming language that provided clear semantics, abstraction and modularity then porting to a new build host would be 10x easier.

It would be an "annoying" or "fiddly" level of work rather than a time sink costing hours and hours.

considering how similar many CI providers are in terms of how you write your tests, I would say that this is either very achievable or not that worth it.

you already can do a lot by writing a bunch of scripts that will be executed on a CI, and just fiddle with differences in like metadata/artifact/how you declare your containers.

and while you are there, you can generate the code CI definitions for more than one CI provider (think of it like "multi-cloud" but for CI approach.

Yup, that's where I want to take the Oil shell:

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

Continuous builds are already written in YAML + shell. Platforms like Github Actions and Travis CI basically use YAML as a really bad syntax for shell scripts (with their own if statements!), and then embed more shell as strings.

So Oil should basically generate JSON like this:

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

and allow you to embed unevaluated (but parsed) literal shell blocks. So I'm adding the missing "declarative" part to shell. That alone gets you pretty far.

Although there are some more language semantics that most builds need, like coarse-grained dependencies, ephemeral or persistent state, etc.

gg is a related "multi cloud" system that's very interesting:

https://lobste.rs/s/virbxa/papers_i_love_gg

I'm writing a blog post about this right now!

----

An improved shell is the natural language for this problem because shell is for gluing tasks together. It's the language of heterogeneity. I view Make as a form of shell with dependencies, and Make has already been parallelized and distributed by many systems going back many years.

Looks like this is what happens when unique companies with a vision hire mediocre business execs. I'm sure there are other ways to monetize while keeping OSS actually free. But you won't get there when your top decision makers treat the core user base with contempt. Now they're yet another CI company I can ignore. I'll be happy to learn another API (Github Actions) or even pay for CI. And it leaves the door open for other innovators (now that you have stopped innovating). Great job all around guys.

Nothing surprising here.

Travis CI made their exit few months ago with a Venture Firm , every venture firm use the same model of "Hibernation" to get cashflow from the platform without new investment.

Only two option to do so :

- increasing price

- reducing cost

Removing the "0$" price for Open Source Project is a disguised way to increase the price...

It's likely the majority of the staff was laid off and the project is now hibernating living from acquired customers not adding new feature or change.

Just being used as a source of Corporate Cash Flow.

This is unfortunate and will cause a lot of migration work, and it was poorly communicated so I can understand the frustration but I'm thankful to Travis CI for their past services.

My project only needs about 30m of build time monthly and the migration to something else may cost me a few hours of work. At my hourly rate that may be significant enough, so for a while I would rather pay a small monthly fee to cover my limited needs.

Our CI ran out on November 20th and hasn't run since. :(

I emailed them last week; I suspect I'll receive a similar email, soon!

Just learned GitHub Actions; seems straightforward...will work on migrating...

I find it funny people are up in arms and complaining, out of all places, on HN, where start-up culture should be more prevalent and aware of the costs it takes to run a business and maintain its operational capacity.

Nothing is free. It might be free to you, but Travis CI has to pay for the compute resources to run your free builds.

At the end of the day, never build your product or infrastructure on free services without planning on eventually paying for it and budgeting for it.

If you want a full CI/CD pipeline, there's plenty of open source tools. You can run it on your own hardware, which is what most do for builds as it's cheaper, or incorporate AWS spot instances if you want to run at the lowest cloud compute cost.

If anyone's looking for something to use for personal projects I currently use wercker and it's really easy to use (specify docker box, run commands) and has a free tier (but it's owned by Oracle so I still worry in the back of my head that they'll fuck it up any day now).

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?

Have you seen https://www.docker.com/blog/scaling-docker-to-serve-millions... and https://www.docker.com/blog/what-you-need-to-know-about-upco... ?

And yes, paid accounts are exempt. But the costs are catching up.

Moving off TravisCI was a good decision. A couple of months back their support stopped responding even though we were paying TravisCI significant sums of money. Their service had all sorts of glitches and wasn’t very reliable.

If they were walking away from people who wanted to give them money, I can imagine they don’t give a shit about OSS projects where they lose money.

TravisCI taught me a hard lesson. Relying on 3rd party for CI is a losing bet if you care about reliability and guaranteed capacity.

Probably the volume of users in the free tier is too big so they need to reduce expenses. It might be like giving away free storage space, too. There may be 0.001% of users that have a crazy amount of usage compared to average. At least my OSS project got to have many free builds, props to Travis CI.

A smart, or at least nice, move for github wpuld be to provide a one-click actions migration at least for the simple travis configs that the majority of projects use.

Have you tried using Jenkins? You should use that instead.

I agree - it's great but... is there a hosted solution? If I just wanna run lint and unit tests on PRs for my shitty open-source project, Jenkins is overkill and not really viable.

Thanks! That was the final push I honestly needed.

Now I've migrated my remaining 10+ Travis-CI builds to a different CI-provider (GitHub Actions).

It feels like a solid upgrade.

What a travisty...okay, I will go pack my bags.

Given the company's track record with ExtJS and Delphi, not surprising to me in the least.

Travis CI was good and easy to use for open source projects. However, reality is... GitHub actions is much easier solution for OSS.

Wasn't it kinda apparent that all of these 3rd party CI services will go the way of the dodo now that github actions and gitlabci exist? How could they compete with a platform built-in CI?

how much are they spending btw?

I just ported the continuous build for https://www.oilshell.org/ to sr.ht for this reason:

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

travis ci alternatives open source

Bamboo. ... TeamCity. ... Appveyor. ... Codeship.

lots more use google

Meh, do I really need continuous integration for my OSS project?

Although inconvenient, it is possible to run these tests on my own computer before publishing.

Apple, Microsoft, Google, Facebook, or whatever could have bought Travis in order to make it remain free. All these companies rely heavily on open source work thus open source project CI. None of them did. Well that's the result of all this.

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.

Microsoft bought GitHub and offers github actions. No need for them to also buy Travis. If Microsoft buying Travis would have "saved" it, then why are you worried about GitHub actions' future?

> Microsoft bought GitHub and offers github actions. No need for them to also buy Travis. If Microsoft buying Travis would have "saved" it, then why are you worried about GitHub actions' future?

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 migrated KeyDB, it didn't take very long at all and now my tests are much more reliable.

Reply on news.ycombinator.com