Re: The new Global Pipeline Library

[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

On Wednesday, September 21, 2016 at 1:55:11 PM UTC-3, Michael Lasevich 
wrote:
>
> 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
>
>
>
>
> On Monday, September 12, 2016 at 12:48:02 AM UTC-7, Sverre Moe wrote:
>>
>> 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.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/fb546394-9fca-478b-a275-3a52899b634c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The new Global Pipeline Library

[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




On Monday, September 12, 2016 at 12:48:02 AM UTC-7, Sverre Moe wrote:
>
> 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/3055d52a-078d-4c25-8f32-b0241e5b7d71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The new Global Pipeline Library

[Tim Downey]

Hellojust 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.

On Monday, September 12, 2016 at 3:48:02 AM UTC-4, Sverre Moe wrote:
>
> 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/0b43e653-335d-4f82-94d2-366c9fb6a214%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.