Travis CI's new pricing plan threw a wrench in my open source works | Hacker News Reader

Travis CI's new pricing plan threw a wrench in my open source works

jeffgeerling.com

214 pointsgeerlingguy142 comments

Hey Jeff,

This is hitting me hard, too. I hope this is the right moment for me to pipe up and say this:

I always just do the minimum with these CI integrations to get my shell script to run. I am grateful for the free minutes they offer open source projects - but any of the deeper integrations, the advanced automation?

No, thanks.

It's not like the other developers who use what I write have any more motivation than I do. No one wants to learn the custom setup steps, not even for the "biggest" of the bunch. (Is that still Github? Who knows? I don't.)

Oh, and if or when I migrate away from a CI system, like right now... Good thing I just kept it simple, you know?

Even for builds that target Windows, I just run a shell script.

I get it that Node and Rust builds really benefit from the advanced features. Anyone care to comment - is it as portable as a shell script?

I don’t think either of them really “benefit from the advanced features” any more than any other language. Also, both have builds that are generally more cross platform than a shell script, given that they’re native on all platforms, and shell is not.

>do the minimum with these CI integrations to get my shell script to run

This. 100%. Where I'm working is migrating from Bamboo to Jenkins. For my team the new process is just calling "./build-test $params" while others are stuck re-implementing various stages, tasks and blah blah blah. Also an added bonus to this is having the full history of changes to the CI/CD process tracked in git.

I call mine make.sh.

Now get off my lawn!

Hey! I started with C projects and make scripts and I long for the simplicity of those days! Obtuse web front ends, bunches of build server pools segregated by random capabilities, job queues clogged by competing developer teams and on and on is no fun.

I wouldn't want something called "make.sh" to install tooling on the computer, though, and that is an important step of CI stuff.

Run it in a docker container so that it does the same in your computer and in the CI worker.

make prepare

make build

make test

make release

Working the same waylocally and in jenkins makes things very easy.

What it does is up to the team but make prepare usually pulls some docker image and install dependencies, make build builds something inside the docker image, make test runs test inside it and make release publishes the docker img

Or use a CI/CD tool that natively supports Docker, like Concourse.

Added bonus is that pipelines are defined in YAML rather than web GUI so you can version control the pipelines themselves and not just any build or test suites.

Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation).

I have heard good things about Concourse, want to give it a try in the future!

> Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation).

There's several ways you can codify Jenkins pipelines, Groovy being just one of them. But ultimately it's secondary to the main design of Jenkins. I'm not taking anything away from Jenkins as a solution - it has been invaluable over the years. But the way we write, test and deploy software has changed since Jenkins rose in popularity and as such we need to rely on different workflows that utilise different tooling. While Jenkins can be used in that way, I'd sooner use something which was primarily designed to be configured via code and used docker by default rather than something that requires enforcement to follow those best practices. That doesn't necessarily mean Concourse, there's Travis, Circle CI, AWS CodeBuild and a bunch of others that all default to that kind of workflow too, but it does mean I'm unlikely to ever advocate Jenkins again in future jobs.

While you’re not wrong I do use jenkins inside docker and use ansible to configure it, it is a bit different than other more modern tools but works fine.

I have yet to see other tools be as flexible (perforce , git, legacy tools, docker, 100s of workers across datacenters etc.)

I’m yet to see a CI/CD tool that can’t do all of that. What you’re describing there is the bare minimum I’d expect any CI/CD solution to do. I guess there might be some hobby platforms for indie devs but they’re not really the use case we are discussing when talking about Jenkins and Concourse.

I've bounced off concourse several times now. The promise is great, but the setup is absurdly complex and at the end I'm stuck with CI in Docker containers (I usually want 1 or more VMs)

Concourse can run as many VMs as you want. The point is those jobs get pushed to a farm of workers (typically VMs) and then docker is used so you have an ephemeral and repeatable build environment. It is absurdly complex to set up though. I feel there is a gap in the market for a Concourse-like solution but simplified immensely.

> while others are stuck re-implementing various stages, tasks and blah blah blah. Also an added bonus to this is having the full history of changes to the CI/CD process tracked in git.

Can't those stages, tasks, etc. be specified in the CI specific config files of the repository? Specifying them via an UI seems horrible to me. At least Github actions is all file-specified (except for secrets).

It still requires conversion of config files and formats vs a script that is the same everywhere.

Yes, that's a valid point, and definitely a disadvantage. I was referring to the point that it's not tracked in git.

Are you moving to Jenkins because of the recent Atlassian license changes?

Not entirely but I think it was the straw that broke the camel's back. Apparently our journey to the cloud will have to wait.

I think there will still be a on premise version of Bamboo going forward, but all the license changes have made my company consider the possibility of moving from Bamboo to something else. That's kind of a shame, because Bamboo works really well for us.

btw. even gitlab does that with their autodevops, besides that they create gitlab-runner:

https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla... https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla... https://gitlab.com/gitlab-org/cluster-integration/auto-deplo...

I found these fascinating, I mean they still have lots of things in their ci file, but basically the have tons of shell scripts that would work without their gitlab-runner.

Not affiliated with gitlab I just tried to figure out how some of their stuff works to have the same k8s integration than their autodevops offers.

Makefiles are the gold standard there, warts and all.

But in every case, unless you encode a whole plethora of hacks in your golden build script, you still need minimal environment setup, like Python + Docker + [insert library here].

Most of my Travis files are only 10-20 lines long, but I work in a lot of different types of environments, so it's not always as easy as "three lines of bash and a docker run command".

Plus I have a number of legacy projects which did use some of Travis' more exotic features, and those will take longer. Not just for myself, but I'm thinking of tons of smaller OSS libraries and projects that are minimally maintained yet have a large footprint under more popular and maintained software!

I'd be interested to have a deeper discussion with you about Makefiles, sometime.

We've actually migrated all our projects off Makefiles. Developers hate having to live within the constraints.

Small plug: consider using Toast [1] to define your CI jobs. It's essentially Make + Docker. You define whatever targets you want (build, test, lint, etc.) and the dependencies between them in a YAML file, and Toast runs them in Docker containers. You can run your jobs on any machine that has Docker—including CI systems like Travis and GitHub Actions. You aren't locked into any CI system, and you can also run your jobs locally.

[1] https://github.com/stepchowfun/toast

Once you start caring about cross-platform, incremental, distributed builds with a bunch of people committing to a monorepo those advanced features start becoming attractive. Shell scripts handle the 'run this build/test task' but not 'pull these artifacts from another set of tasks, run this task to produce a bunch more artifacts, cache them for later.'

In these scenarios the lines between build system, package manager, and task runner all become pretty blurred. Haven't found an all in one solution that I would call "portable" yet.

Sounds like your describing what I like to call a fancy build system

Something like Bazel[0], Buck[1] Pants[2], etc. One of their main features is robust caching of build artifacts, which is helpful for larger projects. But they require some major investment compared to your typical `scripts/build.sh`.

[0]: https://bazel.build [1]: https://buck.build [2]: https://www.pantsbuild.org

I have a lot of ideas (or rather, one idea) about how to fix my CI problems and "fancy build system" is pretty apt. Bazel is the closest thing I've seen to what I want.

Gradle can also do everything imaginable, we've managed to get rid of basically all our horrible bash scripts and wrote most build stuff using Gradle API and using a proper programming language (put actual code in Gradle's buildSrc/, only configure it in build.gradle, and you've got a extremely powerful build).

sweet summer child.

Shebangs are also your friend, if your primary language can be used that way.

The cons of that solution are that there’s a tendency to make them ornate, and the trap of circular dependencies. Reusing an internal library in your build scripts, you have it building itself which can get out of hand quickly.

> I always just do the minimum with these CI integrations to get my shell script to run.

Absolutely. Moving CI systems always shows up where your build logic has leaked into the CI system, rather than staying in your repo.

If you can't identically build your code from the command line and from the CI system, you're going to have problems.

You want coworkers and collaborators to have such an easy time validating build failures locally that only an idiot or an asshole won’t do anything about a problem they may have caused.

Developers hate being thought of as idiots, and being an asshole is a problem you can take to HR. So for the people who don’t pitch in on general principle, straightforward processes help bring them around. And in general that means not leaning on clever CI features, and instead leaning hard on the CLI tools your ecosystem supports.

There are exceptions to every rule of course. Features around scheduling have little to no impact on what gets built and how, just when and why. Similarly, analytics have second order effects on how and when, but once a problem is discovered you can mostly ignore them for a while. Integration with external tools and services on the other hand, should always be questioned. Do I have another way to do this mostly outside of the CI system?

My .travis.yml for a node project is pretty simple: https://github.com/serprex/openEtG/blob/542c645c53dba36d6653...

Python's easy too: https://github.com/serprex/aespython/blob/c3256b656308af8119...

A Rust repo I contribute to has a .travis.yml not created by me, but still pretty simple: https://github.com/dpc/hex2d-rs/blob/master/.travis.yml

edit: updated node project to Github Actions https://github.com/serprex/openEtG/commit/4196992bb23ce43f34...

I don't understand this reaction and the reaction of many people in this thread. To me it looks like choosing beggars, maybe I'm missing something.

Travis-CI was giving a ton of computing power for free, no questions asked. That was incredibly generous but had certainly a gigantic cost and it powered many OSS projects for a long time.

Yet how can we complain that they can throw money around, some says that it will reduce the number of new users that discover the service and the number of paying client in the long run (many are saying this but are not paying users anyway) but it's not like the number of potential clients is unlimited anyway and at what point it becomes to costly to get the last ones.

Why would this be a "private equity" thing, you can't always loose (or invest to get more users) money. Does your company sponsors the infrastructure of that many OSS projects? Would it be willing to cover the costs of all servers used by OSS projects for Travis?

Not sure if would work, but it might be worth trying to have some kind of "donate CI time for this project" button on the platform.

Could be onetime payment or a recurring donation (charged together with whatever payments you have for the platform).

There’s a lot of things Travis ci could do. This is a great idea to help offset their costs, they could also have made their platform better to bring in more paying companies. They haven’t at all kept up with competitors as tooling and build processes have evolved in the past 9 years (namely easy to use docker-native test environments, and parallelization options for big codebases).

I agree with the parent comment, it’s bizarre to blame this on the new acquiring company and to be mad about this development. Travis ci has been asleep at the wheel for many years, and projects have been benefiting from it with huge amounts of free compute for years, but now the free money has run out.

TravisCI bought goodwill and marketing of their paid offering by offering free builds for open source products.

Effectively removing or severely restricting that benefit will essentially lose the goodwill and word of mouth marketing.

It's true that to criticise someone giving you something for free is being a "choosing beggar", but that's not really what's happening here. TravisCI has bought something with their free offering, so it's fair that they lose that when they revoke that offering.

Oh boy, I just moved my projects from travis-ci.org to travis-ci.com after the builds stopped happening on .org.

(Despite the travis FAQ that said "we’re making a number of changes to the travis-ci.org infrastructure to ensure the service will remain as reliable and available to you as it always has been until [it goes away Dec 31]", that was not the case, builds simply stopped working on .org. https://docs.travis-ci.com/user/migrate/open-source-reposito...)

I actually had not seen that announcement at all, this is the first I'm seeing it. So I'm in the same position as OP, I maybe should not have spent time migrating my projects to travis-ci.com. Although I guess this buys me a bit of time to move to github actions instead.

Travis is the reason that many people DO CI at all, in my experience. They made it so easy -- and free for open source -- that there was no reason NOT to do it. Then once you see the value of it, you are hooked, you can't do without it. But I think the number of projects doing CI (open source and not) skyrocketed because of travis. Prior to travis's entry on the scene, CI was not nearly as universal as it is now.

So to say that offering free CI to open source is "unsustainable".... I dunno, they managed to do it for 9 years, were they losing money the whole time?

I think the free service for open source literally created the market. Or expanded it exponentially. It was the first exposure a lot of people had to CI, and they took that first step because it was so easy and free.

And now we're hooked. If there weren't other free alternatives like Github Actions, I don't know what open source would do... we all know we can't develop this stuff without CI, but so many open source projects simply don't have a budget for it.

All three companies I worked for that ended up paying for a beefy Travis CI enterprise plan did so after getting hooked through the open source offering and wanting more concurrent runners and faster builds.

Without that funnel, and knowing it's all integrated deeply in both GitLab and GitHub, I wonder where Travis CI could ever expect growth again... but that's probably not the end goal anymore, just milking the current paying clients and maintaining the status quo.

"that's probably not the end goal anymore, just milking the current paying clients and maintaining the status quo."

Yep, that's private equity. I won't forget it again.

If it makes less and less profit every year even that's probably fine, eventually they'll shut it down, as long as they made back a multiple of what they paid by that point, then it was a good investment.

It's sad to me just as an engineer, that travis is actually really well-built product, it works magnificently and sets a high bar for ease of use, because of many hours of work that developers who cared put into it... and it's now just going to be allowed to slowly sink into the sea.

Yes, private equity hates recurring profits. Obviously.

Not what I said.

> I dunno, they managed to do it for 9 years, were they losing money the whole time?

Probably. Many "startups" these days are not profitable for years as they burn mountains of VC money to gain market share and drown out competitors.

> we all know we can't develop this stuff without CI

Of course we can, we just down't want to.

True. We have just learned what an advantage CI is to software quality and developer productivity, expectations for both of which have been raised because of pervasive use of CI.

Many people wound up discovering/learning that and raising expectations because Travis's extraordinarily easy-to-use and reliable, and free for open source service, got them to try it out and discover the benefits. People had been talking about how everyone should be doing CI before travis, but I think travis played a major role in significantly increasingly how many people were actually doing CI (and thus learning that they didn't want to do without it's benefits), changing the way software is developed. Which is to the credit of those who developed the original travis service, for sure.

I think it really created a market, by offering something with very low barriers that 'hooked' people. Now we're hooked.

Lately as I’ve been getting (more) frustrated with Bamboo and spending time noodling with kubernetes and JAMStack. I keep flirting with the notion that there’s a new generation of CI tool out there waiting to be discovered, one that steals a bit of brain- and problem-space from all three.

One that could more easily be set up by individuals, making it amendable to open source, possibly with some small degree of federation.

I am rooting for the SourceHut CI[1][2][3]. Along with other services it has proven useful even at the current (alpha stage). Also it's the only one that supports both FreeBSD and OpenBSD (NetBSD support is unfinished [4])

[1] https://builds.sr.ht/

[2] https://man.sr.ht/tutorials/getting-started-with-builds.md

[3] https://man.sr.ht/builds.sr.ht/compatibility.md

[4] https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/...

At a glance, it doesn't seem to support neither Windows nor OSX, any ideas if it is supported with your own builder/runner or if sr.ht is working on supporting it in the future?

To plug another CI service, there is https://ci.cppget.org with focus on C/C++. It's free and unlimited for open source projects, including Windows and Mac OS.

The HN thread from when Travis's purchase by Idera (private equity) was announced, Jan 2019:

https://news.ycombinator.com/item?id=18978251

I had pretty much already learned that "bought by private equity" means "run away as fast as you can, they are going to gut it", and I suspected as much from the travis purchase... but I didn't take action, hoping it would not be true, and not wanting the work of moving projects away. Next time I'll remind myself, no, really, you know what "private equity" means, start looking for an escape now on your own timeline before circumstances give you a deadline.

I mean, I expected this to happen, but with some amount of lead time. In this case they literally made the change the night before they announced it!

and subsequent layoffs posts

https://news.ycombinator.com/item?id=19218036

That's when I started recommending clients make plans to move to another provider

Pretty much any time there's an acquisition of a company, followed by a firing of a significant fraction of the engineering staff, one should run away from it.

Sucks though for Travis CI users, I used it in the past and it worked well.

Not surprised.

Travis CI is owned by Idera, Inc. who also own Sencha who make Ext.js -- a pay-to-use JavaScript framework.

First thing they did when Idera, Inc. bought Travis CI? They gutted the Travis CI team.

That's Idera, if they buy anything you use, run!. Private Equity is all about milking the cow till the cow dies.

> who also own Sencha who make Ext.js -- a pay-to-use JavaScript framework.

I pity anyone who's paying for Ext.js (self-described as "The Best JavaScript Framework In The World"). That is some ancient shit right there. They must have some poor sods who're really, truly, stuck if they're managing to get people to pay for it. I guess at least you get support in your quagmire. But good luck finding quality developers who want to work on an Ext.js project...

I worked with extjs 2 and 3 for years and honestly productivity was as high or higher than angular or react. It was a game changer and allowed us to build things an order of magnitude faster than before. I really liked it. What it lacked was a good responsiveness story, and by the time they added that I was already gone, first to backbone and later to angular and react.

The amount of vendor lock-in of Extjs is massive though. It had its own JSX-like pseudolanguage for describing UI that was impossible to port to anything else. Moving away meant a total rewrite.

I’m on my first gig involving front-end now, with ExtJS 3.4. A few years before I joined (was able to observe the team from a periphery) they tried using Sencha’s 3.x-to-4.0 migration tool, which left the app in a state still needing attention to every LoC. The post-Idera layoffs aren’t making 6.x look too attractive.

While I have some sympathy. I also think that expecting travis-ci to effectively donate hours and hours of CPU time a month to endlessly run tests on hundreds on minor projects from one guy is exactly why this change happened. It's unsustainable.

This "one guy," if you will, is responsible for a majority of the ansible galaxy modules that are out there.

Far from a bad actor just utilizing CPU time for pet projects, Jeff's code is probably in use in a large majority of companies that use Ansible, mine included.

How much money does your company contribute to Jeff?

Bingoooooo. If his code is so crucial to your company, you should probably be donating to him to help pay these bills so then companies aren't the bad guy for giving thousands of dollars away for free so you can benefit off other peoples work.

100% this! People can’t possibly complain when companies charge for their tools. If an open source project is important to an organisation, they better start donating.

Nitpicking here, the vast majority of companies that use Ansible do not use galaxy.

The travis-ci.org website still lists this lol,

"Testing your open source projects will always be free! Seriously. Always. We like to think of it as our way of giving back to a community that connects so many people."

My heart skipped a beat. Why is it extremely difficult to be honest about wanting to make a profit one day?,

After some of the previous TOS changes, I finally found the motivation to move to a self-hosted CI on a VPS. I’ve been entirely satisfied since migrating, and it’s been a truly low touch experience. Not for everyone I’m sure but for the low cost of the VPS I’m getting my value out of it, certainly not proving to be a maintenance drain as I’d feared, just updating it on a CRON has served me well.

Are there good tools to help with this for people who are used to a hosted CI and want to replicate some of its features? (I'm just curious, I'm not in that situation myself.) Or is the cloud/SaaS instinct so pervasive now that very few people are trying to do what you're doing?

If you’re comfortable with AWS or any other VPS provider, there are Ansible and Docker flavours of most common tools. I’m a fan of Jenkins but the competition also offers some well defined pathways to get this going easily, and all of them offer a somewhat similar way to define builds automatically in code. My go-to is the github org scanner plugin that can watch for new repos with a Jenkinsfile, and will happily manage creating the automatic commit hooks if a new one is found giving you a very similar level of ‘magic’ integration to what the SaaS tools offer.

There is Concourse CI [0], which appears to be simple to set up.

[0] https://concourse-ci.org/

It might be because I'm more familiar with the syntax, but I find gitlab-ci easier to reason about than github actions. At least, it's a single file instead of a workflow and any number of actions.

This is to say, if I were in Jeff's situation, I would seriously consider moving to GitLab (with mirrors in github for visibility), or at least setting up their ci to trigger from github.

Though maybe I'm just speaking from lack of experience, as I've only set up actions in one project so far.

I love gitlab-ci for this exact reason: you're not vendor-locked-in in any way. Running out of credits ? Just run your own gitlab-runner.

Travis has an FAQ whose URL says "open source repository migration", but whose on-page title says "Migrating repositories to travis-ci.com"

Travis Staff accounts in the travis "community forum" were linking to this FAQ as recently as 9 days ago, which still at this moment contains a question:

> Q. Will Travis CI be getting rid of free users? #

> A. Travis CI will continue to offer a free tier for public or open-source repositories on travis-ci.com and will not be affected by the migration.

https://docs.travis-ci.com/user/migrate/open-source-reposito...

This would seem to be grossly misleading, if not simply wrong info? There are still a bunch of travis users on travis community forums trying to figure out what's going on and why travis-ci.org seems to have stopped working (also different from what the FAQ says), who don't seem aware of the pricing change.

The first line of the document is "On May 2nd, 2018 Travis CI announced that open source projects will be joining private projects on travis-ci.com!", which also includes this FAQ:

> Q. Will there be lower concurrency for free accounts on travis-ci.org?

> A. As part of the shift of infrastructure from .org to .com and needing to make sure all users have equal access to resources, free and open-source .org accounts will have concurrency reduced from 5 to 4 concurrent jobs. Concurrent jobs have not changed on .com, so please consider migrating your repositories as soon as possible if this is an issue.

So... that's all not quite right, it turns out. They're providing an FAQ about "free accounts" without saying there no longer is no such thing as a free account, and "open source projects" are "joining private projects on travis-ci.com" only in the sense they can choose to pay for the same plans as private projects.

It's true that nobody owes us anything for free, and the free support for open source CI for the past 9 years has been a gift...

It's also true that they are not being particularly transparent (an understatement; if they don't fix that FAQ soon I'm just going to call it lying) or gracious in how they are handling this transition, for an open source community that has come to rely on them.

This is what hurt the most. I knew the migration to .com was happening. And I expected the perks (like 5 concurrent jobs) to be slowly removed over time.

But to go from the status quo to 1000 build minutes and that's it in one day, with literally no lead time.

That's what caused the wincing. I'm sure many of the engineers who were laid off at Travis after the buyout are shaking their heads this week.

I expected perhaps they would eventually limit the number of build minutes you got per month.

I honestly did not expect they would eliminate free CI for open source altogether. With virtually no notice. Many people STILL haven't noticed the announcmeent, the FAQ is still misleading them.

> They're providing an FAQ about "free accounts" without saying there no longer is no such thing as a free account, and "open source projects" are "joining private projects on travis-ci.com" only in the sense they can choose to pay for the same plans as private projects.

https://travis-ci.com/plans

Was the "free plan" added after you commented?

> Free Plan

> Free

> - 10000 Credits

> - Unlimited unique users

> - Private & Open-Source Repos

> - Windows, Linux, MacOS

As a logged in user, that redirects to a settings page where you can choose your plan. A tooltip has some more detail for the free option:

> Free Plan is trial plan. The credits will not be replenished.

It's not clear if that's actually true - some people have had emails suggesting there are 1000 free credits (100 minutes on Linux) per month.

Mouse over the (?) icon. "Free plan is trial plan. The credits will not be replenished. Switch to Free Plan if you want to cancel your subscription."

So, yeah, there is something they call the "free plan". If gives you 10K "credits" that once they are gone they are gone (I'm not sure exactly what a "credit" corresponds to in terms of workers/minutes, but could probably find it somewhere).

Do you feel like this is what you expected it to be, that they are being transparent about the fate of open source projects that previously had free CI? You can say you do, it's your perspective!

But why move to another CI provide that will be under the same commercial pressures ultimately? (Handing out free compute is bad for profits).

As someone pointed out here the other day. With build minutes as a concept they're inherently incentivized to keep old slow gear running as well.

I reckon self-hosted gitlab is a good bet, but admittedly tricky for big FOSS projects that need to be public

Because it's easy to use, it works well, and when it doesn't there are 3 other competitors ready to take over.

Travis CI could shutdown overnight, there's Circle CI and AppVeyor doing the exact same thing. They take pretty much the same configuration so there's nothing to adjust.

>and when it doesn't there are 3 other competitors ready to take over.

Apparently the transition is painful enough to warrant a sizable hn discussion though.

I've been using Travis on a bunch of my opensource projects and was wondering why builds were getting queued for ~a day before they'd run, I guess I got my answer. :/

I don't really want to lock myself into GH actions (ideally, I wouldn't be on GH at all), does anyone have any suggestions for alternatives? I don't mind paying some money, but the almost $1K/year for Travis' lowest tier is about an order of magnitude more than I can justify. I've also got plenty of compute laying around if anyone has suggestions for something self-hosted.

Have you looked into CircleCI?

I've used it in the past, but when they finally killed off the 1.0 builders (?) my company went to an "internally" hosted Jenkins[1] server and I haven't played with any of the 2.0 stuff. Have you? How do you find working with it?

[1] I did also ask about selfhosted stuff, but I'm not willing to host Jenkins for myself. I've heard nothing but complaints about managing a Jenkins install. It's been fine as a user (if a bit confusing), but I really don't want to admin it.

Not the person you're asking, but we use CircleCI, and it's fine. The YAML config language is okay, it gets the job done and hasn't been horrible to maintain or modify. Though we only have a few steps in each.

My current gripe is that there doesn't seem to be any way to declare that one pipeline depends on another, though I may just be missing something in the docs.

What I'm trying to do is have my front-end feature branch builds run against the build of matching back-end branch, but there doesn't seem a way to declare "this build should depends on the output artifact of that build".

I don't really want to have to wire it up myself using their API.

If they're in the same repo you can do this using workflows. If they're separate repos I don't think you can do this without using their API.

Yeah, it's separate repos. Interesting to know about the monorepo option, though - thanks.

Also happy with CircleCI here. Main problem for us is their limited support for efficient builds in monorepos.

We use circle for a lot of stuff (the latest version). It's pretty easy to learn. You can pick up the basics in <30 min.

I have been GitHub Actions ever since they released, but used to use TravisCI before that. There were one or two projects where I used CircleCI and it seemed more mature that TravisCI.

Github Actions really is a freakin awesome product. Yeah, there's lock-in, but their free plan (and cheap Pro plan for individuals) offers a great value. And, really, CI is CI; if you ever need to migrate, even for this guy with hundreds of projects it should only take a couple days. Once you've seen one CI yaml file, you get the gist of what all of them do.

Other options:

* Gitlab CI. Good value, great integration with Gitlab, has integration with Github.

* CircleCI. Something of a gold standard in CIaaS among growing companies. But, it goes down a lot, and the new UI isn't an improvement. But, it works and its a good value. Word of advice, I'd avoid using their "Orbs" if I were you. You can accumulate a lot of lock-in with those, and they're infamous for stability issues. Instead, use their docker builder and just build a base docker image with all the stuff you need installed.

* Buildkite. Really cool product; they handle the control plane and the UI and webhooks, you host the runners. Its a simple binary or docker image you can install anywhere. If you're looking for something with low lock-in that's still easy to manage, Buildkite is a great option. I'll warn you though: if you're going to do any kind of cloud hosting for your runners, and you want to build docker images, best to avoid their dockerized runners. Just install natively on a linux box, either manually, with an AMI, etc. Docker-in-Docker sucks; not impossible to get working, but not worth your time.

* Jenkins/JenkinsX. If you want something with zero lockin but also hard to manage.

* AWS CodeBuild/CodePipeline/CodeDeploy. There is, like, no one I feel comfortable recommending these options to, but people still use them because they're AWS.

I'm quite happily using a self-hosted Drone (drone.io) instance, though I don't have much experience to compare it with with other CI systems and my use case is probably not the most sophisticated one. Team is quite responsive, especially considering I'm a free tier user.

I really like Drone. The way “drone exec” works for local builds is really good. Hopefully getting bought by Harness doesn’t ruin it too much, but they already seem to be setting up to split it into versions/tiers.

Almost all current CI systems suck at building Docker containers :-(

Hey, one of the people responsible for orbs (primarily writing and maintaining our first-party ones) - curious if you can elaborate on "infamous for stability issues". Obviously it's hard to argue against the lock in, but I am aware that GitHub Actions has a similar system.

> Gitlab CI. Good value, great integration with Gitlab, has integration with Github.

Yep. Now I'm thinking on migrating my AppImage build scripts (Travis CI + Transfer.sh used for my projects on GitHub) from Travis CI to Gitlab CI. Hope, that there is simple "3-step switch" option.

Really appreciate those FLOSS projects which already use "Gitlab repo + Gitlab CI" to build & provide builds/artifacts, e.g. GrafX2[0], Inkscape[1], etc.

[0] https://gitlab.com/GrafX2/grafX2/-/jobs

[1] https://gitlab.com/Inkscape/inkscape/-/jobs

One thing people forget about GitHub Actions is that you can self-host the runners for unlimited CI minutes (or custom hardware/os combos)! Just like on GitLab CI.

https://docs.github.com/en/free-pro-team@latest/actions/host...

Azure Pipelines has been really good for us. Much much more reliable than travis, and decent pricing.

For self-hosted, I've heard really good things about build-kite (https://buildkite.com/) although I've not used it myself.

I can’t see where build-kite is self hosted. It seems like you must use their SaaS dashboard which makes it DOA for me.

The build agents are self-hosted. So it would work for the GP where they are open to hosted services but have their own compute that they might want to use.

Sourcehut is something you might want to look at. It's modular, so you use what you use, and ignore the rest.

The CI they offer makes no assumptions about where your repos might live (git is git. Who cares who the host is), and offers the stuff you might need like secrets, ssh keys, etc. The images they supply for testing actually seem more extensive than the other players.

And if you really want to self-host it... Go ahead. The whole of sourcehut is open source and reasonably well documented. You can host your own build server with minimal fuss.

[0] https://sourcehut.org/

Interesting, I didn't know it would support pulling from other git hosts. It looks like their CI even has an API integration with GitHub at least for PRs. That's looking like a potential winner. Thanks for pointing that out.

GitLab CI

I always had insane amounts of queue time on gitlab's CI too. I know they have self-hostable runners, do you know if those work from behind a firewall so I could run them on hardware I have at home?

Also, do you know if it's possible to use gitlab CI as a merge gate on github PRs?

Hi there, GitLab team member here.

To answer your questions: yes, you can configure the Runner to work behind a firewall [1] and you can use GitLab CI for GitHub repos [2].

Hope that helps!

1 - https://forum.gitlab.com/t/how-does-communicate-gitlab-runne... 2 - https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/#pipe...

Cool, thanks!

We had been paying ~$500/month for the open-source project (https://dvc.org) even before this new pricing model, and migrated to GitHub Actions recently- works like a charm. The only issue that we have now is Windows builds- machines on GH have a bit less resources, but it's good for us to optimize it anyway.

I had to change CI many times.

From jenkins to gitlab... From travis to github actions...

So I build this small project that helps me to change faster without touch in real CI logic.

https://github.com/rosineygp/mkdkr

I think your problem is bigger than mine, but this kind of approach can help you in the future.

> For almost a decade, Travis CI made it possible for me to build—and maintain, for years—hundreds of open source projects.

Then what about paying for it? The service is definitely very valuable to this person.

This. If I had a cloud hosted CI tool, I would gladly allow open source projects to use it. But they would be lowest priority and there would be limitations on how often builds could happen and/or volume of contributions.

Large corporate backed opensource projects should absolutely be paying for tools like Travis CI. Just because it's open source doesn't mean there isn't money floating around.

It's not super hard to rent a VPS or Physical Server somewhere and spend a few hours setting up <insert ci tool of your choice).

It's not the setting it up that's preventing someone like me from self-hosting these kinds of tools. It's the maintenance, security, accessibility, etc.

More time on all that (or risking hacks and having more downtime) equals less time actually working on the projects being tested.

Well, their lowest paid tier is $69/month. I dunno about you, but that's way more than I can justify spending to be able to support doing work for free. If they had a $50/year or so plan that just restored the previous open source plan, I'd be more willing to consider something like that, but >$800 a year puts it firmly out of my price bracket for what it offers me.

This. I am willing to pay but there's no way I can spend my yearly "save for a new laptop every couple years" budget on one SaaS for projects that generally contribute $0.00 to my bottom line.

This is why I use GitLab with self-hosted runners for all sorts of esoteric platforms, then use their linux runners for the basics. I don't like to freeload, so I do have a Bronze subscription which includes a certain number of monthly CI minutes for private projects, as mentioned here: https://about.gitlab.com/releases/2020/09/01/ci-minutes-upda.... But I rarely make use of it. Also note that there are special arrangements for Open Source projects.

I can totally understand limiting the number of minutes available. It must cost an absolute fortune, and having it unbounded makes it easy to abuse. Having to pay makes developers have to consider if they really need to go overboard on huge build matrices and limit themselves to something reasonable. Likewise for constraining the amount of network traffic. If you don't want to blow your budget, then self-hosting is an obvious and easy choice.

The point is, like with almost all open source work, the funding has to come from somewhere.

If I'm an open source software maintainer, and I make a project that is used by 3,000 companies, helping them generate $Xmm in revenue... how much of that money ever trickles back to the maintainers? The typical answer is $0.

Some maintainers are lucky to have some form of corporate sponsorship, others spend many cycles on some form of marketing to build up some kind of financial support (tip jars, Patreon, etc), but the pricing for Travis is astronomical for non-enterprise usage.

But as I said in the post, I'm grateful for what I got for the 8 years I had it. And I'm happy that GitHub/MS is now running with that gauntlet.

Reading your post, I realized that I'm a company (albeit a very small one) that profits from your work and doesn't pay you.[0] I use your Nginx role in my open source product[1], and I use several of your other roles in my development environment. I just signed up as a monthly sponsor.

Thanks for your fantastic contributions to the Ansible ecosystem and to open source in general. Apologies for my past freeloading!

[0] https://mtlynch.io/retrospectives/2020/11/

[1] https://github.com/mtlynch/ansible-role-tinypilot/blob/b56c1...

Ha, thanks so much! I'm trying (and having at least moderate success) to make it so I can devote half my weekly 'work' hours to pure OSS work, and the sponsorships are getting me close!

Interesting. You put in work, Travis CI puts in work, but the surplus accrues to a third-party. Hmm. Unfortunate.

It's possible that most OSS won't have CI servers in the future. I don't imagine that's the end of the world but it does suck.

Then your are in a position similar to Travis until now: offering a lot of value for free. You need to find a way to monetize the project(s). Only one of all those companies need to give 100 bucks a month to pay for the CI + extras.

Travis CI wasn't going to remain "free" forever, especially with the new owner (which owns Sencha as well). They want to make a profit, open source free builds are not making a profit.

> 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 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 or discuss a renewable amount)

Sounds like a tedious, repetitive process. If only there were a way to automate creating support tickets on a schedule...

I think everyone should move from Travis CI, especially private repos. Idera bought the project that has no future, and it wants to get the money back. It won't get any better.

Idera has fired a lot of Travis CI engineers, and your private repositories are now at risk. They can save some extra money on security.

It seems to me if it takes you many hours to migrate your project from one CI provider to another you're doing things wrong.

Ultimately your .travis.yml file is a proprietary format for a service that you have no control over. You probably shouldn't have built your project's future on the assumption that it's always available.

Ideally you should have your own testing infrastructure in scripts or test frameworks. And your travis file shouldn't do much more than installing dependencies and running the stuff that's under your control. Put all the logic into the stuff you can control - and next time you find out that your favorite CI provider is no longer nice to you you simply use another one, the migration should not take more than a few minutes.

That's exactly how I have 95% of my travisfiles configured (15 or so lines to describe Travis config and install a couple deps, then '[testtool run]'. But I have over 200 projects to finish migrating.

What kind of monstrous CI process can take 4 weeks to migrate?

I know from experience that CI takes a lot of time, but even the very worse one that I have worked so far (dozens of parallel runs on different machines and a thousand lines of yaml) only took me 3 days to migrate.

Have you read the article? The author has literally hundreds of repositories on github.

Each one takes a few minutes (even with automation doing the lion's share of the groundwork). I have migrated around 130 repos so far, and have somewhere between 40-50 left. Some of the last ones actually used more of Travis CI's environment features, so they'll take longer to migrate.

Thanks for this pointer, Jeff. I just spent some time adding another test in travis-ci on one of my projects, and this HN post got me to go in and set up the Github actions and badge. Side effect: The test ran in 1 minute on Github where Travis-CI took ~20.

Frustrated by this as well.

Have spent several days over the past few months working on a reimplementation of Nix support to make it possible to wind down "community" support without forcing projects to find a new CI.

Feels like a lot of wasted effort. :/

How about GitLab and your own runner ?

It's a real PITA isn't it.

One thing I will say - I like the way that you've done your migration. I'm very wary of using defined actions written by GitHub or otherwise, because it seems to me that it leads to vendor lock in for CI.

Ditto, plus it's hard to lock in versions for specific 3rd party actions and keep them updated. You either get 'latest' and hope the 3rd party is trustworthy, or you have to enter in SHAs.

I don't know how the author could expect a free build service to last forever.

I don't. And as I said in the post, I'm extremely grateful for what I got.

I was already migrating projects for a while, and long term may even go back to a local server for builds if GitHub pulls the rug out too. But allowing a service to manage the build system for me saved/saves a good chunk of time.

Travis is trash anyway. I've switched to CircleCI years ago and I'm happy with it. Also completely free. PS: I'm in no way affiliated with CircleCI, I'm just a happy customer.

The new pricing model announcement on HN:

https://news.ycombinator.com/item?id=24964601

I moved my open source repos to GitHub Actions from TravisCI after experiencing 6+ hour build queues. So far, GitHub Actions has been great and I love the Super Linter!

Get a cheap server and just self host drone. It’s been rock solid for me. Although I am using GitHub actions more, drone powers all of more heavy duty docker builds.

Drone has recently been bought by Harness. Will it still be around in a year or two?

Good question. Running the old version will still work for the foreseeable future. Since it's on github Im sure someone would just fork it anyways.

Also just noticed I'm running a really old version.

Did not know about the pricing change (no email or any attempted communication it seems). Will be moving to GH actions immediately, bye bye Travis.

It sucks when people start charging for stuff.

> I just spent the past 6 hours migrating some of my open source projects from Travis CI to GitHub Actions

Man. Sounds like my personal hell.

I’ll never understand how people motivate themselves to run projects. When I think about it I just envision doing a bunch of crap like that, dealing with issues people file, etc etc. No thank you.

Reply on news.ycombinator.com