I'm finding that simply moving the entire jenkinsfile into a single vars method works well enough, but they've taken this another step further by moving all the separate "def" methods called from the main method into separate vars methods. I wouldn't think there'd be any technical reason why this would be a problem, but I'm occasionally seeing weird symptoms with these "second-level" vars methods. I find that sometimes it gets to the point where it calls one of those methods, and then just fails the build at that point without any diagnostic at all. My workaround for those issues has been to simply make an exact copy of that second-level method and define it as a "def" method inside the main file, and that fixes the problem entirely. I didn't even change any of the code of the method, I just copied it into the main file, and that fixed the problem.
On Tuesday, April 9, 2019 at 9:37:32 AM UTC-7, David Karr wrote: > > I work for a very large organization, on a project with many teams, > working on many microservices, all of which were generated from a > home-grown application template system. Most of the Java-based > microservices have a very similar build process. In fact, most of the > projects have an identical Jenkinsfile, with some small parameter value > differences (which are set in a different system, not in the Jenkinsfile). > > Over time, we've evolved the template and common features, including > modularizing and cleaning up the Jenkinsfile. A small shared library was > developed, to hold some of the core function definitions, even though the > basic structure of the build was still "in-line" in the Jenkinsfile. > > The latest version of this template has taken reuse just about as far as > it can go. The entire Jenkinsfile for most projects will be a small > properties block to override some defaults (that are not set in the other > system), along with a single method call, including the shared library > reference. The shared library has now expanded to specify the entire build > process, from that one method call. > > There are a handful of services in the collection that will still have > some custom changes (all in my domain), so I will reference a branch of the > shared library in those Jenkinsfiles. If my custom changes are eventually > accepted as standard (many of them have been), then they will be merged to > the master branch and I can change our Jenkinsfiles to use the master > branch. > > I'm describing all of this for background. What I'm asking the community > is, is this a reasonable strategy? I can't help the feeling that this is > taking reusability a bit too far. I can't give any technical arguments > against it, so I'm just looking for some perspective. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/fdcf2b2e-7c28-4183-93d5-0960c865ae0b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
