Ask HN: What CI do you use instead of GitHub Actions? | Hacker News Reader

Ask HN: What CI do you use instead of GitHub Actions?

3 pointsrmunn8 comments

With GitHub's recent instability, I'm seriously looking into alternatives. But the one piece of the puzzle I haven't figured out yet is GitHub Actions. I've used both TeamCity and Jenkins in the past, and have no desire to go back to either one; GHA, for all its flaws, was just so much better of an experience than TeamCity or Jenkins, for me at least. I've read about multiple alternatives to GHA for CI, but it's hard for me to tell just from the documentation what they feel like to use.

So, for those of you who have used left GitHub Actions and are using a different CI solution, I'd like to ask: what did you settle on? Why? Are you happy with it? And how does it feel to use it? Do you feel like it's invisible and gets out of the way, or do you feel like you're constantly having to massage its configuration all the time?

View on HN

Why do you need a CI at all? You can use a queue like Oban on your own server to kick off jobs. And with AI you can add new jobs, so long as they are well defined, in a few minutes and schedule them however you like. I only recommend this because I use a similar system. If you are planning on GitHub's recent instability to be improved in the future, I would not get your hopes up, they have a long history of instability.

We use GCP Cloud Build for most of our CI needs, and then Argo and Kargo to deploy things.

Cloud Build is generally pretty straight forward to use and we rarely have to mess with pipelines after initial setup. It's easy to make new images with any tools you need for your build process.

Triggers and repo connections are a little annoying to setup, but if you get a little terraform module set up it's not too bad.

Still love CircleCI. They're one of the most mature in the space. Not as flashy as GHA but gets the job done.

I looked at their docs. Their "Debug with SSH" feature is something I would have liked to have had many times in the past: instead of adding a CI command to cat a log file to the terminal, then examining it with GitHub's inadequate log viewer (which seems to bug out, at least under Firefox, when logs are too long), I could have SSH'ed in and examined the log files with my familiar tools.

If I may ask, what about CircleCI have you found particularly nice? What tools does it give you that you would miss if you had to move to a different CI platform?

This is exactly what my team told me when they switched from Concourse CI to CircleCI. I was surprised, this wasn't really discussed, but the pressure on the team to deliver features was increasing, and they were struggling to much with all the tooling instead of delivering functionality. So they deciced to switch to something not so sexy but dependable and stable. Funny thing, about 1 year later we got acquired by CircleCI :)

I like to compare CircleCI to a Volvo, not the most sexy thing in the world, but when you need something dependable that gets the job done and helps you to focus on what really matters, getting from A to B, it's one of the bettter choices.

(disclaimer, i'm still with CircleCI)

Gitlab CI with some remote runners on a VPS that I already have (so I can keep myself on the free tier). Works perfectly.

If you don't mind my asking, how much setup did you have to do on the remote runners? And/or how much time do you find you have to spend on ongoing maintenance on those runners? Have they been fire-and-forget other than occasionally doing a `docker pull` to update them, or have you needed to fiddle with them every other week?

I've installed once via CentOS package manager and upgrading is just a command line away.

Setting up is also a straight forward command line. I rarely have to worry about it.

As you said, pretty much fire-and-forget.

Reply on news.ycombinator.com