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.
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.
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?
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?
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.
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)
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?
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.