That said, GH actions is really new and full of imitations / weird stuff as well. I still think GL offers more bang for the buck in 2021.
Another option is using something external like Drone CI, Circle CI, etc... Some of those look nice, but I've never tested myself.
I could go on and on, Github Actions are horrid compared to Gitlab. I wish, wish wish I could go back but I don't have that power here. Github doesn't have scoped issues like Gitlab, the issue board is so lacking, "projects" is stale and featureless so many things.
But I AM the one who deals with the aftermath. I've spent days fixing one simple github action and I have plenty I don't even wind up deploying they're so problematic.
I've heard Jenkins is a nightmare to administer (not sure about the new versions). Seems like an opportunity: the power of Jenkins with modern sensibility.
Every new permutation of parameters is a new chance for something to go wrong, and there's basically no sane way to unit test or validate any of your "helper" functions, so they're all write-once-change-never.
Which is not necessarily a problem inherent in Jenkins— Jenkins just gives you more than enough rope to hang yourself. GitLab CI can get silly too, but culturally it inherits from the much simpler Travis model, where you're basically expected to just be wrapping some other build tool (eg, tox from the Python world) rather than rolling the whole thing yourself.
You end up with this:
https://gist.github.com/Faheetah/e11bd0315c34ed32e681616e412...
Yes. One thousand times this.
If you are running simple scripts it's fine. If you are using the declarative pipeline, it's fine. The moment you start adding Groovy you'll be down a path that is filled with sadness and anger. Mind you, even the folks behind Jenkins will advise you not to use any complex Groovy scripts(including for performance reasons - you can easily overwork the jenkins master).
I've been focusing on Concourse because it forces the usage of containers for everything. You don't have to care about what's installed in the worker node, you just use a container that has the stuff you want. Simple inputs and outputs.
You _can_ do the same sort of thing with Jenkins (but be aware of all the bugs still open regarding containers). But Jenkins doesn't force you to do anything, nor it gives you an easy and out of the box solution to string containers together. Left unchecked, you have your reproducible builds running in completely unreproduceable magical build machines – that noone really understands how it all works.
Did a migration of a few hundreds of pipelines from one server to another and it exposed a lot of dependencies we didn't know we had. Plugins, jars, packages installed in build machines, you name it.
If you must use Jenkins, please try to avoid Groovy to the max, write anything that's non-trivial as an executable (even if it is a bash script) and call it from the main pipeline. Use containers if you can to avoid build machine dependencies. Try to use declarative pipelines too unless your jobs are very simple, and avoid the 'script' blocks. Do not use the scripting pipeline to avoid inviting groovy to your home.
You can thank me in a couple of years.
Mind you, the Groovy stuff was implemented as an afterthought, and if you aren't handy with Groovy (I am) it can be challenging to learn. But compared to the horrible GUI-driven alternative, it was a no-brainer in the end.
Really, the more you're doing CI, the more you want scripts - doesn't have to be Groovy. I'd honestly be perfectly fine just doing things with a bash shell on a vanilla linux install. I only use Jenkins because my team insists on it, for what? So we can put a web UI in front of CI. I'd even tend to agree that with supply-chain attacks being what they are, and jenkins being a never-ending fountain of security patches, putting a web UI in front of CI isn't worth it.
But at least the groovy part makes life bearable.
My company extracted us from github+teamcity paradise to force fit us to gitlab, it's not going well. Try both and for real, build a real project pipeline and see if that works for your dev before moving to either.
A lot of our Jenkins issues came down to “we are not very good at managing Jenkins”, but even if we where the massive jump in productivity, flexibility and team independence we saw after rolling it out makes me believe it’s just better.
Then there's dependencies between jobs which has gotten better lately but again it seems less developed compared to Jenkins. I also managed to kill the web UI with some of my pipelines when using dependent jobs because the javascript fails somewhere deep when trying to visualise the pipeline and the page just stays blank.
Honestly it really depends on what you're doing. If you're mostly replacing automated builds and tests triggered by git changes then GitLab works just fine.
Jenkins has felt like an unfinished weekend project for going on ten years now. It may once have been state of the art, but that was in a time when people barely knew what a xmlhttprequest was.