Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Retriever for testing pipeline steps of a project itself. #64

Merged
merged 5 commits into from
Sep 29, 2019

Conversation

marcusholl
Copy link
Contributor

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?

The retrievers available up to now are designed for testing
a pipeline which makes use of pipeline steps. In the focus of
the test is a pipeline, not the pipeline steps provided by a
shared lib.

The retriever provided here helps with testing pipeline steps
provided by a shared lib project itself.
@stchar
Copy link
Contributor

stchar commented Sep 26, 2017

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

@marcusholl
Copy link
Contributor Author

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
Copy link

jimcroft commented Nov 2, 2017

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
Copy link
Contributor

brianeray commented Feb 8, 2018

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
Copy link

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 stchar added this to the 1.2 milestone Mar 11, 2019
@stchar stchar self-requested a review March 11, 2019 10:36
@stchar
Copy link
Contributor

stchar commented Apr 4, 2019

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

@marcusholl
Copy link
Contributor Author

@stchar: done

@ozangunalp ozangunalp merged commit d3d7695 into jenkinsci:master Sep 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants