Travis CI Hopes to Clear up Confusion… Again – InApps 2022

Continuous integration (CI) platform Travis CI announced last year that it would be introducing a new pricing model, following its long-awaited move from travis-ci.org to their new travis-ci.com domain, and ever since it seems that everyone is confused about how to proceed. Shortly after the announcement last year, the company offered a blog post in clarification, writing that it “recently had a lot of feedback and questions from the Travis CI community and beyond about the future of open source at Travis CI.” This week, the company offered yet another “update and clarification” on its open source terms, leading off with almost the same exact introduction about feedback, questions, and confusion.

While the problems seen at Travis CI are certainly not isolated — just last week, we wrote about how crypto-miners had overrun Docker Hub’s autobuilds — it seems that the company has run into a different problem entirely: clearly communicating the issue and its solution with its customers.

Not to overstate the case, although some seem under the impression that users are leaving Travis CI in droves, but curl creator and lead developer Daniel Stenberg penned a blog post this week outlining the reasons why he was saying bye-bye to Travis CI and moving the open source project’s builds to Zuul CI and Circle CI. For Stenberg, it seems that everything boiled down to poor communication and what he sees as a broken promise from Travis CI to provide free builds for open source projects.

“The new domain also implied new rules and new tiers, we quickly learned. Now we would have to apply to be recognized as an open source project (after 7.5 years of using their services as an open source project). But also, in order to get to take advantage of their free tier being an open source project was no longer enough,” wrote Stenberg, citing wording in a recent email from the company that said that projects “must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)” to be considered open source.

As for the broken promise, Stenberg cites wording previously posted on the Travis CI website that read “Testing your open source projects is always 100% free! Seriously. Always. We like to think of it as our way of giving back to a community that gives us so much as well.”

As a paid maintainer of curl, Stenberg said they were no longer eligible for free builds on Travis CI and that they ended up moving their builds as of June 14. Another part of the issue for Stenberg, he said, was that when curl ran out of credits for builds, they reached out to Travis CI, but never got a response. He doesn’t seem to be the only one.

Just two days after Stenberg’s blog post, Travis CI offered its latest clarification, noting precisely some of same the complaints made by Stenberg.

“We recently provided revised terms of service directly to open source customers via email, which caused some confusion,” wrote the Travis CI team. “Our intent was to ensure the infrastructure we have designated for open source projects is used exclusively by projects that align with the goals of the open source community versus projects for expressly commercial purposes. We understand that other organizations contribute to the open source community through donating things like developer time, and these contributions will in no way limit open source projects from building on Travis CI for free.”

Moving forward, Travis CI says it is offering “a Zero-Credit Partner Queue Solution whereby developers building for open source repositories on sponsored infrastructure receive more seamless access to Travis CI builds for free,” rather than requiring them to reach out to the company by email. “Developers simply need to modify their open-source project’s YAML file to use the appropriate environment without having to worry about credit consumption,” they explain.

For Stenberg and the curl project, at least, it seems that the move is too little, too late.

This Week in Programming

• Visual Studio 2022 Preview Is Out: You’ve heard all about Visual Studio 2022 and its 64-bit update, and now you can get your hands on Visual Studio 2022 Preview 1, the first release to include the new 64-bit platform. Microsoft says the goal of the release is to “test and tune the scalability” of this new 64-bit platform, which it hopes will get rid of some of those pesky errors you might have run into in the past with the 32-bit version. The preview can be installed alongside other versions and Microsoft is urging extension authors to update their extensions for 64-bit, also warning users that many extensions won’t be immediately available in Visual Studio 2022. While this preview has mostly to do with 64-bit (as well as an update to IntelliCode), Preview 2 is on the way with what they say will be “an exciting slate of new features and performance improvements.”

• GitHub Desktop Improves Drag & Drop Features, Gets Native M1 Support: The latest version of GitHub Desktop is out and, like many other tools recently, has added native support for Apple’s stylish new M1 silicon, which it says will improve performance and reduce crashes. Beyond that, GitHub Desktop 2.9 builds on some features introduced in recent versions by “expanding drag and drop to allow you to squash and reorder commits in your history, amend previous commits, start new branches from earlier commits, and more.” To see the features in action, either download the latest GitHub Desktop or head on over to the blog post for some animated GIFs of the drag and drop goodness in action.
• Go 1.17 Beta Released to Work Out The Kinks: While Go 1.17 isn’t due to be released until August 2021, the Golang team has released a beta of Go 1.17 to get started with testing the latest version of the language. Go 1.17 will not, as initially suggested, include fuzzing among its new features, which the release notes say include just “three small enhancements to the language.” An article at Infoworld dives into this latest release, noting that the language features are intended to “simplify writing code that conforms to unsafe.Pointer’s safety rules.” In addition, the Go compiler also “implements a new way of passing function arguments and results using registers rather than the stack,” which is expected to improve performance and reduce binary size.

• Red Hat Offers Self-Hosted GitHub Actions: Adding upon features it released late last year, Red Hat this week launched the ability to deploy self-hosted GitHub Actions runners on Red Hat OpenShift, making it possible to run workflows on your own cluster instead of GitHub’s. Why would you want to do this, when GitHub provides the infrastructure already? Red Hat is glad you asked. They say that self-hosted runners offer a few distinct benefits: they work with GitHub Enterprise Server, they have no usage limits, and they have persistent disks. The new tools to make running self-hosted GitHub Actions on OpenShift easy include OpenShift Actions runners, a Helm chart to deploy pods from those images, and an Action to automate the Helm install, building the runner management into your workflows.
• Shipwright Brings Container Builds to Kubernetes: One more from Red Hat, which teamed up with IBM to create Shipwright, a framework for building container images on Kubernetes. Citing the increased focus on supply chain security, Shipwright brings the container build process directly into the Kubernetes infrastructure, making it so there is one less place to secure. Shipwright uses “familiar Kubernetes-style APIs” and runs workloads using Tekton, and makes available “an array of modern container build tools like Cloud Native Buildpacks, Kaniko, Buildah, Source-to-Image (S2I), BuildKit, and ko.”

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.

Feature image via Pixabay.