GitHub Actions and GitLab.

I personally found both of those to be paradigm shifts (I went from Hudson to Jenkins to Travis CI to GitLab to GitHub Actions). Travis CI introduced self-serve test infrastructure configuration-as-code, GitLab introduced composability and API integration, GHA introduced many more API features (like various kinds of event sources) and better composability. Each transition also took more hosting headaches and compatibility issues off my hands.

+1 to this. Travis, Circle and Jenkins are entirely in the rear view in this area for me now. My only concern about Actions has become that I use it too much.

I have very little experience with GitHub actions but it seems much more limited and even worst it ties you to a single vendor

We run everything through TeamCity. Not going to claim its the best tool in the world but it's certainly the best I've used, and it's fairly straightforward to work with!

We use TeamCity here as well. Pretty limited in the options we have since we have most of our stuff in Perforce.

I definitely prefer TC over Jenkins though. The Jetbrains support for TC is also really good and they have been helpful whenever we contacted them or opened an issue on their public tracker.

TeamCity works well but can be a bit expensive.

It has a Kotlin DSL that is quite powerful and flexible, but of course you need to know your way around Java to make the most of it.

Custom plugins is also an option if you need something special that is not provided out of the box.

Even though I have moved on to Azure DevOps Services, it's still good to see that JetBrains have fixed a 10 year old feature request.

https://youtrack.jetbrains.com/issue/TW-17939

I would rather use Jenkins for all of eternity than use TeamCity again. TeamCity is probably the worst CI/CD product out there.

Can you give some examples?

Its been a while, but basically horrendous UI/UX, unintuitive way to create jobs and manage variables, things like that. I don't know if it was completely rewritten in the last 2 years but it was dogshit awful before 2019.

Concourse: https://concourse-ci.org/

It takes some getting used to, but I really got to love its concepts for resources/inputs/outputs and how they work together to get you actually reproducible builds.

I must admit that I got put off by the lack of abstractions for the common use cases. The resources/input/output model is so primitive that it almost feels like programming a Turing machine.

Edit: Took a look again: The situation might have gotten better since I last played with concourse

It doesn't parse tests. It doesn't track test success/failure/runtime. Because it doesn't parse tests, it can't show you the output from only the failing tests. The UI is horrid. It's so far inferior to almost all it's competition, I have no idea why anyone would use it.

Can you explain a bit more what do you mean by "it doesn't parse tests"?

Concourse explicitly wants to not know anything about the outputs of your jobs. Most of the other ci products will have _some_ method (integration with common test runners, markers in output) to figure out how many tests you've run and display them as a collapsible outline, or something similar.

Because the ci system is aware of your tests, and perhaps a filename/test description, it can keep stats on them over time.

This is an ancient version of teamcity [0], but it shows how it knows how many tests were run, how many passed, and that there's one "new" failure in this run vs previous runs.

This lets it tell you which tests are slow, which are flaky, all sorts of history of those wrt to state of the associated repo, etc.

Not having these sorts of things once you have them is like flying blind.

[0] https://i.imgur.com/ywB7u11.png

Really love the expressivity of the config syntax and the domain model in Concourse.

Seems to be a bit harder to integrate with other systems (like GH check results), and alas the community is pretty small (which probably factors into the first point).

Zuul CI, it works great for both small scale and scales very easily. It's the CI developed for openstack but it's also used by BMW and Volvo Cars for example. https://zuul-ci.org/

Bamboo from Atlassian is really good IMO but obviously not free.

If you are Atlassian shop, then yes. Otherwise, don't even bother

I like Drone, and run it on my own systems. It integrates nicely with Gitea.

Links for the lazy:

https://www.drone.io/

https://github.com/drone/drone

+1 for drone.

Note that it's intended for dockerized deploys, so it won't fit if you're not deploying containers.

That’s not true. It runs whatever you want, inside a container with your code. You can deploy from within that container however you like. You can run tests that just pass/fail, and throw away the container result. You can ssh or rsync things from within the container to other remote hosts, and throw away the CI container. It uses containers to ensure build consistency, but you don’t have to use them to deploy containers just because your jobs run in them.

Oh thanks for the correction!

Drone Enterprise is fantastic. Rough around the edges and the docs are really lacking, but it's just so god damn simple and effective.

Gitlab.

Both Gitlab and Bitbucket Pipelines fall under the "sufficient" category in my book. I've used both in large productions deploys and, they for the most part, get the job done. Gitlab has moments where it doesn't work - and one needs to go check the status page... and at times report an outage. But honestly, I still place it in higher regards than Jenkins.

Yes gitlab so so much nicer to run on than Jenkins.

Sure there is something missing for more elaborate build pipelines, but not enough missing to block you.

The best think about gitlab vs Jenkins is that there are no plugins. So it’s very clean what is gitlab and what is your config of it.

Whereas Jenkins has so many plugins and config for the plugins that it’s hard to say where Jenkins ends and your build pipelines begin.

Oh no my username is a an actual product :/

Though this looks pretty awesome!

Buildbot as a project has been around since 2003... with a username like that I am surprised you hadn't heard of it before!

Buildbot was the first CI I ever deployed at a company a long time ago. It came before Jenkins!