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

I just spent the past 6 hours migrating some of my open source projects from Travis CI to GitHub Actions, and I thought I'd pause for a bit (12 hours into this project, probably 15-20 more to go) to jot down a few thoughts.

I am not one to look a gift horse in the mouth. For almost a decade, Travis CI made it possible for me to build—and maintain, for years—hundreds of open source projects.

I have built projects for Raspberry Pi, PHP, Python, Drupal, Ansible, Kubernetes, macOS, iOS, Android, Docker, Arduino, and more. And almost every single project I built got immediate integration with Travis CI.

Without that testing, and the ability to run tests on a schedule, I would have abandoned most of these projects. But with the testing, I'm able to keep up with build failures induced by bit rot over the years and review PRs more easily.

What went wrong with Travis CI?

From the outset, Travis CI was built to integrate with GitHub repositories and offer free open source CI. At one time it was showered with praise on Hacker News and elsewhere for its culture and ethos.

But as the years passed, other CI systems became much more popular, until late in 2018, GitHub dropped the bombshell that was GitHub Actions, and it seemed like the outlook for Travis CI went to:

K.C. Green - This is fine dog in fire

Now, to shed a little more light on where, precisely, things went from bad to worse, I put together this little timeline of Travis CI's most important moments in relation to open source builds:

Note that we're not yet caught up to the end of the timeline. There are many other open source developers and projects out there still using, who either haven't found the time or motivation to migrate to (or elsewhere, ideally), as evidenced by this massive daily backlog of build jobs:

Travis CI backlog of open source builds

Those who, like me, finished migrating to in the past couple of weeks to get out of that backlog hell are now realizing that we are going to have to beg for extra build minutes after our 1000 'trial plan' build minutes run out:

We will be offering an allotment of OSS minutes that will be reviewed and allocated on a case by case basis. Should you want to apply for these credits please open a request with Travis CI support stating that you’d like to be considered for the OSS allotment. Please include:

  • Your account name and VCS provider How many credits (build minutes) you’d like to request (should your run out of credits again you can repeat the process to request more or discuss a renewable amount)

Sorry, but no thanks. I don't have enough time in my day to send off emails every few [days|weeks|months] requesting extra build credits so I can continue maintaining my open source projects.

Looking in the gift horse's mouth

As I said earlier, I am appreciative of the acceleration in my own growth and career that Travis CI enabled over the past decade. And there so many other services with generous offers for open source maintainers that I appreciate and try to support in any way I can (often financially, as far as I'm able).

I just fear that, like when Google shut down Google Code in 2015, this will have some cascading affects on some of the smaller and less-maintained open source projects some of us rely on, but don't think about.

And I know personally, this whole project is going to soak up around 4 weeks worth of the time I can devote to my free open source work, meaning that's a month out of my open source development time that's just vanished into thin air. Not fun, and not motivating.

I'm lucky to have many supporters on GitHub Sponsors who have helped make my work more sustainable, but most open source maintainers have either a fraction of the support I do, or none at all.

Migrating to GitHub Actions

GitHub Actions logo tagline

Ever since the January 2019 buyout, the writing's been on the wall—especially after so much of the existing engineering staff was laid off. I had already started building newer projects using GitHub Actions for CI instead of Travis CI.

I had planned on slowly migrating over the course of a few years, since many of my older projects still work, and are used, but are not in active development.

But the actions Travis CI took this month—without any prior notice—forced my hand, and now I'm in the middle of probably a 2-to-4-week-long process of moving everything off Travis CI as fast as possible. Getting behind on build failures for a month would lead to a pileup of small issues that will really bog me down.

Anyways, enough of my sob story. I wanted to link to some of the tools I used to migrate, and show how I automated some of the migration, so you can do your own more easily!

The majority of my open source projects are Ansible roles (a large part of the Ansible content I maintain), and to get them migrated, I automated as much as possible. You can see all the details in this GitHub issue: Convert from Travis CI to GitHub Actions.

For each role, I used this Ansible playbook to write new GitHub Actions CI and release workflows using a template. Then I adjusted all the 'cron' values so the Actions won't all run at the same exact time each week.

Then I created github-repo-manager, a simple little project that uses PyGithub to make changes across all or a subset of my repositories. I used it to add a GALAXY_API_KEY secret to all repositories in my account that began with ansible-role-* (for repositories in a personal account, you have to add GitHub Actions secrets to each repo—for organizations, you can create shared organization secrets... much more convenient!).

Finally, I went in and manually migrated the small part of the Travis CI build definition that was custom to each role (e.g. some have a one-dimensional build-matrix, some have a two-dimensional, and they all have a different mix of OSes they build on).

I had already started building many new projects (both Ansible and Kubernetes-related) on top of GitHub Actions, even presenting on the process a few times (e.g. Continuous Ansible testing with Molecule and GitHub Actions). The news earlier this week just accelerated my migration plans for older content from 'when I get time' to 'right now.'

Luckily, GitHub Actions does pretty much everything I could do in Travis CI (so far... I still have 36 more unique repos to go!), and the only real complaint I have is the continue-on-error functionality is no substitute for Travis CI's allowed_failures option.

There's still a bit of work to be done, and I'm trying to prioritize things so I don't leave my most widely-used projects (like Drupal VM) without active CI for too long, but at least this story doesn't have a bad ending.


Heh, I just noticed in the open source repository migration FAQ it says:

Travis CI will continue to offer a free tier for public or open-source repositories on and will not be affected by the migration.

Not so much.

I also saw that, but chalked it up to them not going through their FAQs and updating them.
I'm thinking this must have been a knee jerk reaction to their "abuse". As the abuse and these changes all happened within a single month. Or they were waiting for something like this to happen and felt it was time to make even more money.

It will be interesting to see what happens and how many people migrate away, or find their offering applicable for their use cases. $15 for 25k credits is not that bad of an offering, but if your burning through their 10k free credits in a day, 25k credits certainly isn't going to help.

I had to change CI many times.

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

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

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

I appreciate the write up.

Do you think There is an opp for folks to listen to repo changes and volunteer build and test cycles for projects using a rootless container runtime?

I have 10s if not hundreds of spare cores I could gift to an "oss build/test @home" project.

I'm not 100% sure as I have never used Travis-CI but I have been testing my actions with '' would this do the same as 'allowed_failures' ?

I also like your idea of splitting out the lint step, so I have taken this idea on board but I have added an additional 'needs: lint' option to the the Molecule job so that it only runs if the Lint job passes.

you've just been screwed over by a corp changing the deal and you're taking refuge in microsoft github? dunno, doesn't seem like a good plan to me, i'd seek firm foss ground with a selfhost option. have you looked at sourcehut?

Same thing happened here with all the free credits getting used the morning of Nov 2 and builds just stopped running. I did submit a request for OSS only credits to last through January (estimated time to migrate away, most likely) that same day, and a few days sent another message asking for an estimated time to hear back on the request. It has now been a week, and I have not heard a response to either message... things aren't looking great, but I'll post an update on the total time waited and outcome when I get a response.

Nice article to spread awareness. I am so frustrated.

Nice writeup, thank you.

On a GitHub project for Drupal I own I posted

"So Long TravisCI, and Thanks for All the Fish"

Economics say that someone has to spend the money for the things you use for free, so it's understandable to change idea, but I agree more advanced noticed would have helped, since OSS developers critically lack the resource that woud be needed to switch here - time.

I started my project to self host all of my Heroku apps on a rpi cluster shortly before github actions was released, but I haven't looked back. Using running on k3s I'm pretty happy with my solution that will pull new pushes to any watched github repo, build, test, and run on any of my domains even .dev thanks to cert-manager.

Nice summary. It feels odd that I didn't see this in "news", since it's showstopper for many projects. Thanks a lot for Actions example, it helped me switching. I'm only afraid that GitHub will announce something similar and we're damned again.
I actually wouldn't mind the credits on travis if it was per month, but one-time budget just doesn't work for me. Also I would go with some kind of "bring your own runner" option, although I understand it wouldn't be easy to implement homogenous environment.

Ah, yes. That would've been a much easier pill to swallow, as it would've at least allowed me to continue using it with my own hardware.