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 t
We’ve taken sort of a middle ground approach with this on our end. We
define standard flows for a particular build system (like maven)
The 80-90% use cases are allowable with our pipeline, consumers only define
eome configuration options in a closure.
For the extra 10% use case, we provide steps
It is a fair approach, however my opinion is that the pipeline definition
(stages and steps) should be in the project pipeline (Jenkinsfile), in the
shared library we have only steps that make only one thing an they make it well
or steps that combine several others, every step has his own unit t
Hi David
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.
>
I th
Sounds like a good system to me. :-)
On Tue, Apr 9, 2019 at 9:37 AM 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
> micr
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
