Goodbye, Travis. (But it's not all despair.)

In its day, Travis CI was a real eye-opener about how useful spinning up a batch of build processes could be. It was fast, free for open source, and neat.

But it was sold to a pretty smarmy company called Idera. And without being told, we were shifted onto a free "plan" with 1000 minutes of compute time.

That's not 1000 minutes a month, that's 1000 minutes total. Not exactly a "plan".

Not only was there no heads up this was going to happen, but the account was in the negative by 3200 minutes. There wasn't really any accounting to know where all these minutes came from or when they started.

In theory we could get approved as an open source organization with a monthly refresh. But on forums people who've submitted for the approval process say they've heard nothing back but a form letter.

If this had been done more straightforwardly, then a $15/mo fee to keep the build farm going wouldn't seem that bad. But with it being done the way it was, this isn't an organization you want to be giving your credit card number to.

Starting Over From Scratch

I pulled out all the Travis scripts and am beginning from a fresh sheet.

It would be good--I think--to have pieces of the build done by different CI services. That distributes the minutes we might use if we're being charged (in free open source points or with dollars). But it would also help look for ways to do things in a CI-agnostic way.

To that end, I began by breaking up @LkpPo's %make.sh script into some isolated bash files, that can be documented and tested as isolated bits of functionality:

%tools/bash/

This way the CI can be debugging the same process that any user could also benefit from.

The highest priority build to get back online was the Wasm builds. So I decided to go ahead and give a shot at putting that on GitHub Actions (which is where many people jumped to).

By having a separate CI just for the Web Builds, the file can be a lot more focused and clear:

.github/workflows/main.yml

And if you look at the output from the build, it's much more coherent to look at than what we had in Travis:

A Successful Web Build / Test / Greenlight Log

This is Turning Out To Be a Good Thing

At first, it felt like just another avalanche of "oh no, not another thing to deal with".

But despite the annoyance of having to take time out to deal with it, this is looking a lot better. The files needed the attention. GitHub Actions are snappy, I gather that other CI have a lot of things going for them as well (I'm interested in looking into Drone.io) So far, the main downside to GitHub Actions seems that your choices for build platforms are pretty limited...this is the list:

https://github.com/actions/virtual-environments#available-environments

Anyway, I guess Travis was sold to a bargain basement and going away for a reason...there's too many better options. It's sad to see something go out like this, when it felt at one point like it really defined a new way of working. But the build process is important enough to get attention and be brought up to current practices...so being forced to attend to it is probably a blessing in disguise.

4 Likes

I am happy this has happened before I had the time to spend my limited resource of free time getting a hold on this service.
This kind of issue is always in the back of my mind when dealing with cloud services in general.

1 Like

Little script become great. Too bad that travis take this turn.

I determined it wasn't going to be worthwhile to try to ask for open source account status on Travis, given that other people were getting no response.

Eventually a formal response did come:

But It's Been A Blessing In Disguise

GitHub CI is way better. (To avoid ambiguity, I'm calling the service "GitHub CI". It gets too confusing otherwise...as Actions are actual specific things, not the service or workflows in the service.)

Take a look through the .github/workflows/ directory. Documented in classic HF-style. :bookmark:

But I'm trying to be careful to stay as service-agnostic as possible (under the circumstances). Where possible, things are done in shell code sections that you could copy and paste into a local terminal if you needed to. That means taking any GitHub-specific syntax and capturing it off into environment variables as soon as possible.

Generally speaking, it's a lot better for breaking things down into reusable pieces, which is kind of a protection against lock-in. The better organized things are, the more hope you have to translate them.

If time were infinite, I'd certainly be trying out some of the self-hosting options, like Drone CI...which has a good premise. But this is moving in a very good direction.

2 Likes

Builds For All Systems Now Operational on GitHub CI

Unlike the monolithic Travis script, each is broken into a separate workflow as an individual YAML file. Code can be reused with shell scripts run in common, and now via the GitHub ren-c-action as well...

(Note: On Travis, MinGW cross-compilation was the only way to get Windows builds since there were no Windows containers to build in. Since we had that working, it's good to keep it working...as long as it's not unreasonable additional cost. Tests another weird build variation. But also, because some open source libraries do not have MSVC-based makefiles. So if you want them to compile for Windows, MinGW with Cygwin or on Linux is the easier way to go.)

:abacus: :computer: :earth_americas:

3 Likes