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

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

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

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

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.