-
Notifications
You must be signed in to change notification settings - Fork 395
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
Update library loading so branch not required for localSource locations. #75
Conversation
I was trying to use JenkinsPipelineUnit to test a library I'm writing. I want to use this from within local copy (clone) of the repo using the localSource retriever. This was problematic as the code required setting defaultVersion (branch) which it then appended to the path to the library root. This PR allows the following usage: ``` def library = library() .name('jenkins-library') .allowOverride(true) .implicit(false) .targetPath(dirPath) .retriever(localSource(dirPath)) .build() helper.registerSharedLibrary(library) ``` where `dirPath` is the project root, without `@master` or other version identifier in the filesystem path.
For clarification, you want to use JenkinsPipelineUnit to test a shared library? If so, this is also related to my question in #70 |
Thanks for following up at #70 (comment) . https://github.com/jimcroft/jenkinslib-example/blob/master/test/com/example/TestCase1.groovy looks exactly like what I am trying to do - Load the current source code which is a Shared Library and test that. |
Sounds to be related to #64 |
FWIW, we (before finding this PR) have locally implemented a similar solution to the same problem. Is there any chance of the project maintainers (@ozangunalp ?) taking this on board, or providing feedback so it could be moved forward? |
This would be great. I hacked up a solution involving a temporary symbolic link to the project in the form |
👍 for this, I have been struggling for months intermittently to add tests to my organization-wide shared library. If a commit breaks a step, it can impact dozens of builds. |
@@ -18,7 +18,7 @@ class LibraryConfiguration { | |||
String targetPath | |||
|
|||
LibraryConfiguration validate() { | |||
if (name && defaultVersion && retriever && targetPath) | |||
if (name && retriever && targetPath && ((retriever instanceof LocalSource) || defaultVersion)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this class should be agnostic of the retriever's "type".
@@ -11,7 +11,14 @@ class LocalSource implements SourceRetriever { | |||
|
|||
@Override | |||
List<URL> retrieve(String repository, String branch, String targetPath) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The real problem here is that the (abstract) concept of SourceRetriever is too tightly coupled with the one of a (git) repository and that we are bending the implementation accordingly. Rather than always requiring a branch and ignoring it when it does not make sense (i.e. in line 18), it would be much better if the retrieve
API had a more generic signature. For example, it could take take a single map instead of the repository/branch
tuple. This would allow us to specialize the map according to the needs of the specific retriever.
Hoping this can be merged soon. I'm using the jenkins-pipeline-unit to test a shared library via maven instead of gradle and am running into this issue with no real way to work around it. |
Any thoughts around merging something like this or #64 to support the "local source code" functionality? |
@mkobit, I suppose this one could be canceled |
I was trying to use JenkinsPipelineUnit to test a library I'm writing. I want to use this from within local
copy (clone) of the repo using the localSource retriever. This was problematic as the code required
setting defaultVersion (branch) which it then appended to the path to the library root.
This PR allows the following usage:
where
dirPath
is the project root, without@<branch>
or other version identifier required in the filesystem path.I'm not a Java or Groovy coder so this PR probably has issues so any feedback welcome (even if it's just pointing out that I'm not using it properly! :) )