Implement a workspace retriever.

[iocanel]

I wanted to validate pull requests send against my pipeline library. So I needed to be able to dynamically load the library in the pull request branch.

With the current retrievers, that is not possible (but I may miss something so please, correct me if I am wrong). So my best bet was to checkout scm and try to load the library from the workspace. To make it work I hacked a simple WorkspaceRetriever and thought it might make sense to share...

[jglick]

Not sure what it is you are trying to accomplish here (there is no test which might demonstrate its usage, or help file, or JIRA issue), but probably you just wanted to use the library step which allows you to specify a library location.

[iocanel]

I think that what best demonstrates my use case is this:

https://github.com/syndesisio/syndesis-pipeline-library/blob/master/Jenkinsfile#L3

For pull request validation shake, I wanted to be able to checkout the library from the pull request and load it as is. As I don't have an easy way of referring to the pull request branch, my only shot was to try and checkout the source and load it from my workspace.

This pull request is adding the retriever that allows me to do so.

[jglick]

More concisely:

library identifier: "syndesis-pipeline-library@$BRANCH_NAME", retriever: workspaceRetriever(WORKSPACE)

[jglick]

Perhaps instead try just

library identifier: '...', retriever: legacySCM(scm)

I think that would address your use case, assuming you were not patching the library after checkout. Needs testing of course. CC @rtyler

[jglick]

(note: no @ in the identifier)

Actually I think that would not work as is, but probably a retriever based on the concept could. TBD

[jglick]

@jtnord / @batmat could my trick above with legacySCM(scm) simplify the testing system you described here?

[jtnord]

@jglick I'm not sure if/where it would help at all. Where you thinking of something specific (e.g. the script.replace("checkout scm", "checkout git://.....git")

/cc @batmat

[schnatterer]

I have been waiting for a feature like this for a long time! However, my use case is different, that's why I like to mention it here FYI:

I've experienced that for complex builds the Jenkinsfile gets kind of bulky and not very maintainable. Now that the build job is code, it would be wonderful to have the same means as for other code. That is, I would like to divide it into smaller (more maintainable units) and unit test them.

See also my question at SO.

Looking forward to using the workspaceRetriever!

[diegorusso]

Folks, any ETA on this?

[tworec]

Gentlemen, will it be pushed forward? I think it is vital option for shared pipeline libs.

[iocanel]

As this covers my needs as is, and I am really tight on schedule, I don't intend to do additional work anytime soon. If anyone wants to push work on this PR please do.

[tworec]

well, how do you use this code then? Tests do not pass and findbugs complains. How do you build and deploy this on your instance?

[samifruit514]

This feature would help a lot for local development. I could just mount my project lib folder in docker-compose and change my files directly

[mfuchs]

Would this have security implications for PRs?

For example, it is possible to configure a multibranch job so that the Jenkinsfile for a PR is only used in the PR job for github users with Admin/Write rights. I suppose the same should also be true for a local pipeline library.

[jglick]

I believe the trick demonstrated in https://github.com/jenkinsci/workflow-cps-global-lib-plugin/pull/43 supersedes the need for this.

[schnatterer]

@jglick the trick works in general. However, it's not possible to load libs from subdirectories. Comparing the questions vs answer upvotes of the Stackoverflow question cited in #43, I presume it's not only me who looks forward to this feature 😉

[jglick]

it's not possible to load libs from subdirectories

#40 probably.

[schnatterer]

TBH I can't judge if #37 or #40 would be the better solution from a technical point of view.

Neither

• PR #37 (which has been dangling here for almost 2 years) nor
• PR #40 (the author closed the issue behind it in the meantime - JENKINS-46721)

look very promising.

From a users perspective I'd like to load shared libs from a subdirectory within a repo. Any chance one of this gets merged eventually?

[jglick]

I can't judge if #37 or #40 would be the better solution

The idea behind #40 is a general RFE which many people have requested. As a special case, it would address your concern here. I had issues with the implementation.

I also see #45 sounds similar to this one in concept.

Any chance one of this gets merged eventually?

Up to whomever maintains this plugin these days. If that were still myself, I would probably just close out the existing PRs and write some things from scratch the solve the basic limitations in a way better aligned with the design of the plugin. Would require dedicated time to think carefully about the approach.

[heyleke]

See #99

[jglick]

As of #172 most of the code in this plugin has been moved to another plugin repository so this PR must be closed. If this change is still needed, please

git clone https://github.com/jenkinsci/pipeline-groovy-lib-plugin
cd pipeline-groovy-lib-plugin
git checkout -b workspace-retriever
git pull https://github.com/iocanel/workflow-cps-global-lib-plugin workspace-retriever

resolve any merge conflicts, and file a fresh PR on the new repository. Be sure to paste a link to this old PR to enable bidirectional navigation.

[iocanel]

Stale, closing

[schnatterer]

@iocanel have you found a solution or workaround?

[iocanel]

@iocanel have you found a solution or workaround?

No, I used a fork with this fix, till my job shifted to completely different areas.