There's also a way to get CUDA working in Docker by passing the device paths, which gitlab-ci-runner can also use.
One reason why Jenkins is so widely used in enterprise companies is that within traditional corporate structures person hours are readily available whereas software purchases have to be approved by someone with budgetary discretion.
It's generally much more expensive to customise and maintain a brittle Jenkins installation than it is to buy a comparatively low-maintenance turnkey CI / CD solution.
However, the people who can do that customisation and maintenance work usually are there already anyway. Therefore people rarely bother with finding the most appropriate or most cost-effective solution but settle for the one that comes with the least resistance.
run 'sh ./build.sh && ./test.sh && ./deploy.sh'
We have gone for middle ground, the pipeline has a small number of discrete steps, but these steps mainly just call scripts defined besides the code within the respective repo. That way one can replay the process manually wherever needed, but we still can easily see in Jenkins where the process fails, including submitting test results to jenkins to see directly in the web-ui which tests failed.You can also call individual steps, which I do from a Jenkinsfile. This way you can still see a nice pipeline woth different steps.
All this runs in Docker. This is integrated almost properly with Gitea (only thing missing is an icon in Gitea on success/failure).
Jenkins is fine behind the firewall. Its not terribly elegant but its very flexible.
That doesn't really help people handle the software well.
I worked with Robert and told him I wasn't a fan of the shared libraries approach because it abstracts the workflow away from the team, when the reality is we want more people to understand the pipeline, not less.
Jenkins itself is a bit of a hodgebodge of legacy crap.
- Plugins that do next to nothing. Hard to reproduce this.
- Inability to run locally; gives you the rope to hang yourself.
- Bit of a security mess
- Upgrade and admin story historically pretty poor; lack of infrastructure as code, etc. Conflicting versions when you restore.
- Unclear story on relying on state. Why isn't my build environment clean?
Jenkins is actually a pretty good tool, especially when you use it well. But once you're been around the block a couple of times and deal with teams failing with a tool, for a variety of reasons, you start to wonder if maybe the complexity of the tool itself is the culprit.
Personally it was easy for me to switch from travis because all my CI scripts are actually bash scripts, so the .yml CI file is just a few lines pointing to those scripts. All I had to do with gitlab was make a base image to be the "CI image" with all the tooling necessary + docker-in-docker.
Upgrades to GoCD have been very predictable, in contrast to Jenkins :-)