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.
I've used Jenkins quite a bit and I like it a log and it's flexibility. The problem is that it has many features but not all have been added in an orthogonal way so can't be combined well. (Pipelines actually made this much worse IMO).
Not the OP, but I’m wary about implementing build logic in a form that’s only executable on a server. Pipelines are one step better than the old style build configuration, but still inferior to just having the whole build/test/release cycle defined in scripts in the branch which can be run anywhere.
We have started using Makefiles for this. Our Jenkinsfiles are only used for the orchestration and reporting. All our applications can be build, tested, and released by our employees on their machines. Works great for us!
I have a simple Python script with a function for each step.
When called with no arg it runs everything; this way I can trivially run a full CI build on my laptop.
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.
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.
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.