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.
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.
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.
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.
Edit: Took a look again: The situation might have gotten better since I last played with concourse
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.
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).
Note that it's intended for dockerized deploys, so it won't fit if you're not deploying containers.
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.
Though this looks pretty awesome!
Buildbot was the first CI I ever deployed at a company a long time ago. It came before Jenkins!