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:

• depend on additional folder/files beyond Jenkinsfile (method and define would be in Jenkinsfile)
• require some changes to workflow-cps-global-lib to support loading from local and from subfolder instead of root folder.
• make users have to understand library folder/file structure even to write simple helper method.

We had a IRC chat about this, which I've attached.

Also attached are images from a Pipeline job that I created as a proof-of-concept.
The code for this POC is in: https://github.com/bitwiseman/hermann/tree/issue/jenkins-library/example

What is not shown/done in the POC:

• loading from a subfolder (not currently supported), subfolder name should default to "jenkins" (maybe?) and be configurable to other values.
• * Worked around by putting the vars folder in the root - this would not work if the project already had a src or vars folder.
• loading from the currently checked out branch/commit (not currently supported)
• * Worked around by hard coding the branch name
• using a library local directive to tell declarative to load a local library
• * Worked around by adding the configuration to the parent Multibranch pipeline job and loading implicitly.
• Using the already checked-out code
• * Shared library simply clones it's own copy. For this small repo, this is fine, for larger projects it would not be acceptable.