For context see: https://jenkins.io/blog/2017/02/15/declarative-notifications/
And the linked bugs, in particular JENKINS-41396.
I've been informed that this is a horrible idea, but I'm going to describe it here just to make sure.
There have been a number of issues and discussions going around, dealing with how to define variables and methods in Declarative Pipeline.
Right now, we can define variables and methods outside of the pipeline section but that is not a supported solution and it is not viable long-term.
As noted in JENKINS-41396, we have a supported way to define variables and methods that we can use in Declarative Pipeline via
Shared Libraries. However, that means I have to spin up a separate repository just to make a helper method that might be used in only one
Pipeline.
JENKINS-41396 and JENKINS-41335 suggest adding sections to the Declarative Pipeline model to allow these things to defined inside
the same {{Jenkinsfile}}. This is also problematic: there are implementation issues, and it means that the distinction between the overall flow
(defined in Declarative Pipeline) and the implementation details (defined in methods, variables, and classes) becomes more blurry.
What I'm suggesting, is we reuse the functionality of "Shared libraries" but support loading from a subfolder in the current branch of the currently checked out repository.
This would have a number of benefits over other solutions, it would:
* reuse existing (and tested) functionality, limiting risk
* not require creating a separate repository
* keep the script code out of the Declarative Pipeline Jenkinsfile
* use the same file/folder structure as Shared Library, getting users familiar with it for when they decide to use Shared Libraries
On the downside, it would:
|
|
|
