Open source plans

Travis CI Discussions & Feedback
1

I sent a support request on 11/20 for my three open source projects (libjpeg-turbo, VirtualGL, and TurboVNC) to be considered for a Travis CI open source plan. Travis CI support replied with a list of criteria for consideration. I believe that all three projects meet those criteria, but I asked for clarification on one of the criteria and never received a follow-up reply.

libjpeg-turbo in particular is used by millions of people worldwide (and may even used by Travis CI, as a matter of fact-- it’s in every Linux distribution and open source web browser I know of.) libjpeg-turbo admittedly has rather complicated builds, which include regression testing, but since libjpeg-turbo is considered to be critical Internet infrastructure, it’s necessary to run those builds as soon as bug fixes (which are often security-related) are pushed. Unfortunately, Travis CI instituted the new credit system right as I was in the middle of a flurry of bug fixes leading up to the libjpeg-turbo 2.1 beta release, so the 10,000 free credits got used up automatically before I was even aware of the new limits. The project’s pace has slowed considerably since the beta release, but because the project’s Travis CI credits are used up, right now we can’t spin pre-release builds with critical post-beta security fixes. libjpeg-turbo is out of funding until probably next June, and I can’t personally afford to pay for more Travis CI credits. I understand your desire to avoid “abusive” uses of your system, but I hope you would agree that providing zero-day fixes for a JPEG codec that is used by millions of people, is an ISO standard reference implementation, and is provided free of charge is not abusive. I am happy to work with you to reduce the credit load of our builds, if you would provide some transparency into how credit usage is calculated.

4 Likes
2

I wouldn’t get your hopes up, I finally got a response to the OSS minutes requests I submitted Nov 21st.

screenshot
screenshot1876Ă—940 70.7 KB

1 Like
3

I’ve migrated VirtualGL to GitHub Actions and am in the process of doing so for TurboVNC, but even for those relatively simple CI builds, it’s a painful process. libjpeg-turbo is much more complicated, since it has to run a variety of builds in order to regression-test various architectures and build configurations. I simply don’t have the project resources to do that migration right now, nor does GitHub Actions provide all of the same features (specifically, it’s really nice to be able to regression-test the Arm SIMD code, since that’s an increasingly popular architecture that has received a lot of attention in the latest major release of libjpeg-turbo.) I sincerely hope that Travis will do the right thing and support a project that is benefiting its company as well as numerous other organizations and individuals worldwide. libjpeg-turbo is both a de facto standard and an official ISO standard reference implementation. If we don’t qualify for credits, then I’m not sure who does. I would even happily list Travis as an ongoing project sponsor, if they provided us with sufficient monthly credits to keep the project going. Most people reading this are using libjpeg-turbo right now in their web browser. Using software on which I basically break even (I lose as much or more money on the project than I earn through funded development on the code), then trying to charge me money in order to spin zero-day fixes for said software, isn’t exactly being a good open source citizen.

4

On the other hand, when I asked about this credit system I was simply awarded 50k extra credits. Which ar of zero use to me because I’ve been having troubles with builds starting, and with the migration to travis-ci.com which have seen no response for nearly a month now. I have no idea what is going on at Travis, but support has gone from super responsive to absolutely none at all suddenly.

1 Like
5

I believe they laid off a bunch of people. Their new owner is a private equity firm, and when a private equity firm takes over your company, sometimes it’s because they want to drain as much blood as they can before killing it.

1 Like
6

If it helps, I have published a Github Action that is creating the build-script from .travis.yml (ported from the original travis-build) and runs it. As I was running into the same kind of problem after migrating from travis-ci.org to travis.ci.com recently (support told me I should do so and while doing credits already ran out within less than three days):

The action allows to keep the same build script process across Travis and Github (as you know integration I guess this is an overstatement). As the cache / language configuration and matrix etc. is not done with this github action but only running the build-script / stages I was able to make the .travis.yml portable (e.g. I kept secrets out of the equation with little conditional edits) while creating the new workflow on Github.

This allowed me to switch off anything from Travis that is possible on Github already, e.g. I went down to 5 build minutes in total per build on Travis from what was 50+ minutes without first porting all the stage scripts (before_install, install, script etc.).

What still needs to be done in the Github workflow is the VM setup if it does not work out of the box, the checkout action and then other stuff like caches/services/matrix. But for caches for example I was first looking to get the build to work. So it’s helpful to do things step by step.

And yes, Travis has some features Github has not. With this action I could reduce to what I can not yet do on Github and keep the rest on Travis.

I will further reduce the Travis usage, that is when I have it triggered, next is only having build on tags. As only the stage scripts are re-used, changing the matrix in the .travis.yml does only touch Travis but not the Github workflow. This gives a lot peace of mind already.

My project is much smaller than yours, so your mileage may vary. I’ll do another project next and will take a look on the portability, it’s really new. But maybe it helps.

/Edit: running example: https://github.com/ktomk/pipelines/runs/1526326034?check_suite_focus=true#step:7:1

5 Likes