There are two Travis CIs...
Tags: devops
Published: 2020-11-16 05:59:12

...and it's confusing for newcomers. When someone wants to use Travis to run tests on the code they push to Github and other Git servers, they can choose between travis-ci.**org** or travis-ci.**com**. Actually, there isn't really a choice, as you can only use the .com site. The .org site won't recognize new builds from my experience.

So how did we end up with two different Travis-CIs? Let's take a blast into history.

## The beginning

Travis CI is open-source software created around 2011. because it's open source technically anybody can run it on their own servers, but Travis CI advises against this because there are too many things to monitor.


> The company notes, however, that the large number of tasks that a user needs to monitor and perform can make it difficult for some users to successfully integrate the Enterprise version with their own infrastructure [[Wikipedia](https://en.wikipedia.org/wiki/Travis_CI)]

So, that's where the two managed sites come in. The domains travis-ci.org and .com were both made by the Travis CI company. Org was used for open-source projects and let you run jobs that take up to 50 minutes, and Com was used for commercial projects and relies on credits as a way of billing your job time. Both of them read special YAML files you create in your project that tells them what kind of test environment to set up, and both can be configured to send results via email, IRC, Slack, and other platforms. They even have nearly identical websites.

## Migration

OK, so all went well and stuff, until one day in 2018 Travis CI made an announcement that they made a free plan on travis-ci.com (they give you about 10,000 non-renewable credits which are spent on build time), and that they will migrate all the .org users and projects to that. And then they will shut down travis-ci.org in 2020, one month from now.

But, the process is not as easy as you think. First you need to opt into .ORG's beta program, and you just need to press a button in the settings to do that. The fact that .ORG still has a beta when it's close to End of Life confuses me, unless Travis CI is going to move all unmigrated projects form .ORG to .COM at the deadline.

Then you head to travis-ci.com and it displays a page listing the Github repositories using travis-ci.ORG which you want to import, and you select the ones you want to migrate.

## Do not sign up for .ORG

Because I did that after the 2018 announcement, and connected one of my Github repositories to it. The result was, my builds were pending and not being ran at all, even though I successfully connected Travis to Github and my .travis.yml file was valid. Unless I opted into for the beta program, I could not add the repo to travis-ci.COM either, so my project was effectively stuck with broken integration tests.

It looks like this happens only to newly registered users after 2018, not existing travis-ci.org users.

## Is Travis CI viable for open source projects in 2020?

This question is for travis-ci.COM. Because users registered after 2018 only get a one time allotment of 10,000 credits, that does not renew, will run out fairly quickly (I did 10 builds and used 450 credits already) and you cannot replenish without purchasing more, it brings up the question of how open source projects will be able to build on Travis without paying up. The answer is you can't, unless you ask their customer support to give you more of what they call *OSS-only credits*, which as you might have guessed can only be used for open source projects (actually only public projects on Github, not private projects there).

Users who were already using travis-ci.org get 10,000 regular credits per month. But this throws new users like me under the bus as now we effectively can't use Travis CI without buying credits.

There are some alternative free CIs that can replace Travis such as CircleCI and Github Actions, which give open source projects a monthly number of credits. Github Actions is even unlimited for public projects, so that is a fine choice to migrate your integration testing to.