Travis CI changes pricing plans

Tooling
1

Quoting from Blog – Travis-CI

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 - Test and Deploy with Confidence[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
2

I believe that’s the general understanding, yes

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

4 Likes
3

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
4

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 WIP: migrate to GitHub actions by ranocha · Pull Request #288 · trixi-framework/Trixi.jl · GitHub. Making Coveralls work with multiple parallel jobs required using their GitHub action instead of the related Julia action.

1 Like
5

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
6

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
7

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?

8

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
9

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.

7 Likes
10

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
11

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
12

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

8 Likes
13

Just to add that the Travis free credit for OS projects is not so “immediate”… there are lots of arbitrary conditions attached to it. This is the email I received from them after asking for the free allowance:

Hello Antonello​,

Thanks for contacting Travis-CI Support! We would love to help.

We offer an Open Source Subscription for free to non-commercial open-source projects. To qualify for an Open Source subscription, the project must meet the following requirements:

* You are a project lead or regular committer (latest commit in the last month)

* Project must be at least 3 months old and is in active development (with regular commits and activity)

* Project meets the [OSD](https://opensource.org/docs/osd) specification

* Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)

* Project can not provide commercial services or distribute paid versions of the software

Does this sound like you and your project? We'd be very happy to support you!

However, if your project does not match these requirements or you have further questions [1], please feel free to ask!

We look forward to your response if you meet these requirements to proceed with the next steps.

Thank you

[1] https://docs.travis-ci.com/user/billing-faq/
4 Likes
14

Technically, this condition can be difficult to meet. Even a FOSS project under GPL can sell the software for money. (People may not buy it if it is available for free, but it is allowed so one cannot commit to “can not”).

15

Thanks for sharing, that’s interesting and, as pointed out by Tamas… upsetting :confused: