I can’t say I didn’t see it coming. Ever since GitHub actions and GitLab CI started started to get the attention, some.projects moved to them at cost of Travis market share.
It was too expensive for personal projects, so I don’t think individuals actually considered to subscribe for paid plans. It’s sad to see them losing like this, because Travis is the CI that I first started to love, after having used Jenkins and mentally justifying to not use Jenkins terrible UX ever again, not to mention the self-host nature.
Thanks for the nice write up, they are some really interesting posts to read.
My biggest complaint with Travis, other than a need for better documentation, is their pricing model / activity limit is based on concurrent jobs instead of actual usage.
We’re a small team and aren’t pushing a ton of commits all day every day, so we weren’t using it a ton overall, but it was still annoying to have two people push at the same time and one would have to wait twice as long to get any results. Paying nearly twice as much for the privilege of avoiding that occasional scenario feels like a ripoff.
A note for those who expect [skip ci] to just work:
The feature doesn’t exist on Github, but can be easily added with an if: !contains(toJSON(github.event.commits.*.message), '[skip ci]') property on the job.
Downside is that you can’t check only the subject line of the head commit, because the conditional expression syntax for workflows is not powerful enough.
That’s handy
Skipping CI seems counter productive. Why exactly would you want to do that?
So you recommend GitHub actions instead Travis CI.
I’m very new with CI-CD but this thread is very helpfull 🙂
How do these minutes work? I just created some pull requests on one of my open source repositories and inspections ran fine on (unpaid) Travis.
Each time I need to open a PR I move that project to GH actions. Travis will be toast in a few years.
Members
Online