The new Global Pipeline Library

[Sverre Moe]

There has been changes in the Global Pipeline Library plugin

https://issues.jenkins-ci.org/browse/JENKINS-31155

Jenkins Configuration => Global Pipeline Libraries

Choosing "Modern SCM" the next drop down list is empty. What does this option actually do?

Choosing "Legacy SCM" I'm able to define a git repository for the library.

According to the documentation:

It can be used in two modes: a legacy mode in which there is a single Git repository hosted by Jenkins itself, to which you may push changes; and a more general mode in which you may define libraries hosted by any SCM in a location of your choice.

Should it not be the other way around for the modes in configuration? Modern SCM should have option to add SCM.

The best way to specify the SCM is using an SCM plugin which has been specifically updated to support a new API for checking out an arbitrary named version (Modern SCM option). Initially the Git and Subversion plugins have this modification

Choosing Modern SCM there is no option in the drop down list. Neither git nor subversion. Though they are with Legacy SCM.

If your SCM plugin has not been integrated, you may select Legacy SCM and pick anything offered. In this case, you need to include ${library.yourLibName.version} somewhere in the configuration of the SCM, so that during checkout the plugin will expand this variable to select the desired version.

For a library in a git repository would I need to tag a specific version?

---

It is great that we now can use a shared library stored with our own Git remote repository server. However until we transition to that have workflowLibs.git work as before.

If I move the shared library to a different SCM I would probably need to remove workflowLibs.git otherwise how would Jenkins know which one to load as I need to load it implicitly.

[Tim Downey]

Hello....just giving this thread a bump as I'm having the same questions.  What exactly is supposed to be the configuration for Modern SCM?  I have been able to get it to work using the Legacy SCM to point at my git repo.

[Michael Lasevich]

I am making an assumption that "Modern SCM" is some new Jenkins SCM API not yet supported by most common SCMs - so I am just ignoring it and using Legacv SCM

As for ${library.name.version} - you use it if you specify branch/tag in GIT or in URL for SVN

Basically when you load the library with @Library syntax, you can (if enabled) specify a version (release, beta, v2, whatever you want to call it). When SCM fetches it, it needs to know what to do with this "version" you specified. So, for SVN you include ${library.name.version} in your SVN URL in global library config, so when it checks it out, it will check out the version specified in your @Library statement. Similarly for git, which has a fixed URL for all branches, you specify fixed URL but use the version variable in your branch specifier (which can point to either a branch or a tag) 

So for example for my "testlib" library, my branch specifier is : 'refs/heads/release/${library.testlib.version}'

So when I do '@Library "testlib@beta" _' in my code, I get branch release/beta

Here is a tiny trick I do here, btw --  notice that I hardcode the "release/" prefix to my branch - I do this to prevent the scripts from specifying any branch other than the one with 'release/' prefix - this prevents developers working on new features from being able to load those features into Jenkins (which for global libs runs outside the sandbox) without a proper peer review (release/*" branches are restricted in my config).

HTH,

-M

[Daniel Serodio]

Your assumption is correct, see this issue: https://issues.jenkins-ci.org/browse/JENKINS-38424?focusedCommentId=271289&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-271289
This is also related: https://issues.jenkins-ci.org/browse/JENKINS-38550 ("Pipeline Libraries" shouldn't show "Modern SCM" if no implementations exist)

Regards,
Daniel Serodio