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.
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.
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.
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:
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.
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?!“.
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...
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.
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!
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.
Since then I have switched a bunch of projects over to Github Actions, fortunately they were all relatively simple enough to make that straightforward.
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...