Add Retriever for testing pipeline steps of a project itself.

[marcusholl]

The JenkinsPipelineUnit framework is very helpful for us. We are some developers as SAP developing Jenkins shared libraries. We use the framework for testing our pipeline steps coming from our shared library.

Testing steps contained in a shared library is not the main focus of the JenkinsPipelineUnit framework, as far as we can see. The main focus is testing pipelines itself.

In order to test our shared library itself we introduced another SourceRetriever. This source retriever registers the coding of the shared lib located inside the project root folder itself (or to be more precise in. the folders vars, src and resources which in turn resides in the project root.

The already available SourceRetrievers are suitable for registering shared libs coming from either a git repo or checked in somewhere into the project sources following a naming convention like $repository@$branch.

Instead of having a dedicated SourceRetriever for making pipeline steps contained in the project root itself available it would also be possible to make the pattern mentioned before configurable so that also an empty pattern can be used.

We think our use case is in general valid. And this is why we propose our source retriever with this pull request.

Are there other possibilities for testing pipeline steps itself - rather than pipelines - without having another source retriever?

[stchar]

Looks great, but there are no tests.
I used to workaround this with a gradle copy task.

[marcusholl]

Bonjour,

thanks a lot for your feedback.

Looks great, but there are no tests.

Yes, if there is a significant chance for getting this PR accepted I will provide tests. In that sense the PR is work in progess, but I'm not able to set the corresponding label. IMO it's better to show up with a PR early rather than investing time and finally it gets refused.

I used to workaround this with a gradle copy task.

We also thought about a copy step. But on our side it is somehow difficult since we have projects on different build systems, (e.g. also maven). The less dependencies to the build system (also as e.g. copy step performed by the build system) the better. Here that would be a minor thing, but as we made that experience on other projects ...

[jimcroft]

Would love to see this or #75 merged and have a supported, recommended and obvious way to test local project source as part of JenkinsPipelineUnit.

[brianeray]

Cool; it would be very helpful to have this.

I hacked around the same stumbling block by setting up a symbolic link in the form libName@master, pointing to the appropriate subdirectory inside the project under test. That allows the regular SourceRetriever to load from the symlink since it has a directory name in the format it demands. This all in a framework that extends the JPU framework (+ Spock) and is in turn used by the pipeline projects needing to test themselves.

The one drawback of this hack is that, at least on our Windows machines, we have to be Running as Administrator in order to have the privilege to create a symlink.

[giorgiosironi]

I copied this class in my project to try it out, but I can't get the loaded steps to use any base pipeline step from Jenkins (e.g. sh or even echo). The test fails with a long stack trace starting with

    groovy.lang.MissingMethodException: No signature of method: sayHello.echo() is applicable for argument types: (org.codehaus.groovy.runtime.GSt
ringImpl) values: [Hello, Giorgio.]
    Possible solutions: each(groovy.lang.Closure), wait(), run(), call(), run(), find()
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:58)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:81)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
        at sayHello.call(sayHello.groovy:2)
        ...

[stchar]

@marcusholl, looks cool, thank you. It also needs resolving of merge-conflicts, could you please do this.

[marcusholl]

@stchar: done