GitHub actions seems the best to me atm

I’ve been using Jenkins for almost a decade and it’s my goto for any CI/CD work just cause of the wide plugin support, documentation, integration with other tools and at this point, familiarity. It integrates nicely with Jira where i can see Jenkins build status for a given story, It shows up as GitHub checks to add against a PR, it can push/pull artifacts to Artifactory, have HTML view of test results, slack messages, open source if you’re into that and it can do a lot more.

We have strict data sovereignty requirements, so we do a lot of self hosting. We are also a kubernetes shop, so we’ve been using the Argo-CD / Argo Workflows combo. I quite like it, there’s a lot of freedom to spin up a container and do anything you want in it while passing results to the next step, it might be too much freedom for some folks though. CD systems have some variety to them since there’s so many ways to deploy code, but CI systems all feel pretty similar to me. The main differences are the format of the instructions you write for the system, and how much or how little it holds your hand.

In the Nix ecosystem, I appreciate Cachix quite a bit. It’s much easier than running a Hydra.

I’ve ran into Drone CI about a year ago and I like it. I wanted to self-host something simple next to my gitea instance, and after a few hours I had it mostly set up. And in the course of a week I had it all figured out, I don’t bother with it any more.

It’s basically hands-free operation the way I have it set up, works with my gitea as said so I’m happy.

Jenkins and GitLab runners. They get bad reputation, but are extremely powerful and easy to start with, much faster than GH actions, more popular and better documented than other enterprise alternatives.

At work I use Jenkins, and I am very frustrated with it. I’ve worked with GitHub Actions, GitLab CI, and Azure Pipelines, and none were truly enjoyable to work with. They’re acceptable.

The last change I made on our project was to send a build failure and build fix notification email on branches to the last committer. (After having disabled branch build failure notification emails because Jenkins (or its plugins) were not able to send to only the branch developer/new change pusher/author a while ago.)

The best thing we did was introducing commit message conventions and convco to verify them, and to generate changelogs automatically.

We’re using Ansible for a lot of stuff, with Semaphore as a frontend.

Semaphore has rudimentary support for CI/CD. We don’t need all the bells and whistles of something like Jenkins, and Semaphore is saving us from having yet another software to know and and maintain.

At work integrating convco last year to verify commit messages conforming to conventional commits and to generate release notes / a changelog - for builds and releases.

Private, the last interesting thing I did was set up GitHub Actions to fork and daily fetch upstream GitLab changes of MKVToolNix to generate releases and release notes on the releases - because they don’t do either. So with GitHub release notifications I now see a release with a change list immediately. https://github.com/Kissaki/MKVToolNix

I don’t have much experience with setting up ci/cd stuff. But last time i tried Circle CI and it was really easy to set up and get working. I’m thinking of looking into GitHub actions soon though.

We use build kite, I like it better as an end user than other things I’ve used (circle ci, Travis, bamboo). I haven’t been on devops setup end of it much so can’t really talk to that end. I’ve liked what I’ve used of gh actions as well.

I’ve been using ConcourseCI because another team manages it and it is integrates with Hashicorp vault.

It’s good. The big advantage is I don’t have to deal with maintaining it.

The downside is their story on GitHub integration is kind of crummy, you have to create your own web hooks because our ConcourseCI instance is too busy for poll based resource checks.