Travis CI changes pricing plans

Quoting from https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing

We love our OSS teams who choose to build using TravisCI and we fully want to support that community. However, recently we have encountered significant abuse of the intention of this offering. Abusers have been tying up our build queues and causing performance reductions for everyone. In order to bring the rules back to fair playing grounds, we are implementing some changes for our public build repositories.

  • For those of you who have been building on public repositories (on travis-ci.com, with no paid subscription), we will upgrade you to our trial (free) plan with a 10K credit allotment (which allows around 1000 minutes in a Linux environment).
  • You will not need to change your build definitions when you are pointed to the new plan
  • When your credit allotment runs out - we’d love for you to consider which of our plans will meet your needs.
  • 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 (like travis-ci.com/github/[your account name] )
    • 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)
  • Usage will be tracked under your account information so that you can better understand how many credits/minutes are being used

It looks like people using Travis CI (like we do) will have to apply for OSS CI minutes again and again in the future…

macOS builds need special care and attention. We want to make sure that builders on Mac have the highest quality experience at the fastest possible speeds. Therefore, we are separating out macOS usage from other build usage and offering a distinct add-on plan that will correlate directly to your macOS usage. Purchase only the credits you need and use them until you run out.

For pure Julia code, it’s often enough to run tests on Linux. However, wrappers of third-party libraries and packages making use of MPI or something like that often do need to run tests on different OS, including macOS.

What are the alternatives - moving to GitHub actions for everything?

7 Likes

I believe that’s the general understanding, yes

That seems to be the most popular alternative at the moment, yes.

4 Likes

Any downside to moving to GitHub actions? I already did that for Documenter and all went well.

The only problem I had was that I could not find anything equivalent to “skip-ci”. I got some hints but could not get anything to work.

2 Likes

I’m also moving all my packages to GitHub actions right now and am quite satisfied so far - we even get more parallel builds which is quite nice! However, I’m also struggling with an equivalent of [skip ci]. Something like

jobs:
  test:
    if: "!contains(github.event.head_commit.message, 'skip ci')"

seems to be okay on push events but doesn’t work for pull_request events.

Edit: An example using multiple jobs in parallel with corresponding setups for Coveralls and Codecov is https://github.com/trixi-framework/Trixi.jl/pull/288. Making Coveralls work with multiple parallel jobs required using their GitHub action instead of the related Julia action.

1 Like

FWIW, the solution that I adopted (re: the lack of “skip-ci” with GitHub actions) was to just separate all the Julia versions I wanted to test in separate actions (see, e.g., https://github.com/JuliaOcean/AIBECS.jl/tree/master/.github/workflows).

1 Like

I am entertaining the idea of moving my projects to Gitlab and setting up runners on my own home server.

Eventually I expect that free tiers will be limited everywhere, as current free offerings will be swamped by people migrating away from ones that are being closed down.

Also, our community should be thinking of fallback CI options for at least core packages in the ecosystem (eg the likes of Distributions or StaticArrays, widely used ones).

4 Likes

The limit is per account or per repo?

Also, as someone who uses Travis but not heavily (only a few packages), do I need to worry about this right now?

Kinda what I was thinking. I’m not a heavy user and will take some time, but not forever, to hit 1000 mins. I’m looking for stability more than anything else. As @Tamas_Papp says, GitHub will likely start charging sooner or later.

1 Like

I think Drone CI is at the moment best self-hosted CI service. It’s fully FOSS, available both as service, runners or both. Both service and runners can be hosted either in cloud (with some free tier for Open Source projects) or self-hosted. Finally, contrarily to Gitlab CI or Github Actions, it’s not tied to any specific Git service vendor (although I read somewhere that Gitlab CI can be painstakingly made to work with other Git providers with some workarounds). Also there are no special paid-tiers, all functionality is available for self-hosted versions.

My favourite combination for self-hosted git repos + CI is Gitea + Drone as both are fully FOSS and easy to self-host. Hope it doesn’t come out as a form of unwanted advertisement. If so, please delete this post. I’m not connected with those projects in any way besides using them. I was just looking for this kind (completely FOSS, with possibility to self-host either in parts or entirely) solution and for long couldn’t find alternatives with features comparable to Github/Gitlab + their CIs. I just wanted to share this findings with Julia community, since from what I’ve seen packages ecosystem heavily depends on GitHub & Travis-CI combination.

6 Likes

Just got GitHub Actions working and solved the skip ci koan. I think I’m happy, I still have a bit of testing to do to make sure the CI banner works. This was pretty painless.

1 Like

Thinking more about this, if we had telemetry data about package usage then perhaps a list of repos for “serious” (= not set up for CI abuse, but actually used by Julia users) packages could be communicated to Travis and similar services, asking them for a small automatic quota.

4 Likes

For users looking to quickly and easily switch from Travis CI to GitHub Actions, I have posted a simple CI workflow file here: Easy workflow file for setting up GitHub Actions CI for your Julia package

6 Likes