[JIRA] (JENKINS-38679) Polling using legacy SCM fails: “Workspace doesn't contain https://svn/global-library-repo${library.myib.version}”

122 views
Skip to first unread message

jglick@cloudbees.com (JIRA)

unread,
Oct 4, 2016, 3:28:02 PM10/4/16
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
 
Jenkins / Bug JENKINS-38679
Polling using legacy SCM fails: “Workspace doesn't contain https://svn/global-library-repo${library.myib.version}”
Change By: Jesse Glick
Summary: Polling using legacy SCM fails: “ Workspace doesn't contain https://svn/global-library-repo${library.myib.version} . Need a new build.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

jglick@cloudbees.com (JIRA)

unread,
Oct 4, 2016, 3:29:01 PM10/4/16
to jenkinsc...@googlegroups.com
Jesse Glick commented on Bug JENKINS-38679
 
Re: Polling using legacy SCM fails: “Workspace doesn't contain https://svn/global-library-repo${library.myib.version}”

the modern scm dropdown is empty

I know, I am trying to find someone to cut releases of the Subversion plugin; currently it is abandoned.

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 23, 2016, 12:54:03 AM10/23/16
to jenkinsc...@googlegroups.com

The issue with global libraries always causing scm triggers to build still exists after subversion plugin update.

jglick@cloudbees.com (JIRA)

unread,
Oct 24, 2016, 10:12:01 AM10/24/16
to jenkinsc...@googlegroups.com

Well if you have updated the plugin then you can use Modern SCM, in which case the originally reported bug does not apply. Maybe there is some related bug. I did not really understand the original since it does not include clear, complete steps to reproduce from scratch.

jglick@cloudbees.com (JIRA)

unread,
Oct 24, 2016, 10:13:01 AM10/24/16
to jenkinsc...@googlegroups.com

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 24, 2016, 10:26:02 AM10/24/16
to jenkinsc...@googlegroups.com
Anton Lundin updated an issue
Change By: Anton Lundin
I see a wierd bug when using global libraries on pipeline.

We have a groovy class with static defines, which lives in a legacy place in subversion and can't be moved.

I've worked around that by configuring a global library:


Every poll scm poll call finishes like:
Workspace doesn't contain https://svn/global-library-repo${library.mylib.version}. Need a new build.

Everything loads just file when i use:
@Library("mylib@/trunk")
import mylib

but the polling bug makes it re-build every poll call.

I use the Legacy SCM api to declare the lib, because the modern scm dropdown is empty.

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 24, 2016, 10:30:04 AM10/24/16
to jenkinsc...@googlegroups.com
Anton Lundin updated an issue
I see a wierd bug when using global libraries on pipeline.

We have a groovy class with static defines, which lives in a legacy place in subversion and can't be moved.

I've worked around that by configuring a global library:

{code:java}
    <org.jenkinsci.plugins.workflow.libs.LibraryConfiguration>
      <name>mylib</name>
      <retriever class="org.jenkinsci.plugins.workflow.libs.SCMRetriever">
        <scm class="hudson.scm.SubversionSCM" plugin="subve...@2.7.1">
          <locations>
            <hudson.scm.SubversionSCM_-ModuleLocation>
              <remote>https://svn/project/data${library.ladok3.version}/legacy/path/mylib</remote>
              <credentialsId>xxx</credentialsId>
              <local>src/mylib</local>
              <depthOption>infinity</depthOption>
              <ignoreExternalsOption>true</ignoreExternalsOption>
            </hudson.scm.SubversionSCM_-ModuleLocation>
          </locations>
          <excludedRegions>/.*</excludedRegions>
          <includedRegions></includedRegions>
          <excludedUsers></excludedUsers>
          <excludedRevprop></excludedRevprop>
          <excludedCommitMessages></excludedCommitMessages>
          <workspaceUpdater class="hudson.scm.subversion.UpdateUpdater"/>
          <ignoreDirPropChanges>false</ignoreDirPropChanges>
          <filterChangelog>false</filterChangelog>
        </scm>
      </retriever>
      <defaultVersion>/trunk</defaultVersion>
      <implicit>false</implicit>
      <allowVersionOverride>true</allowVersionOverride>
    </org.jenkinsci.plugins.workflow.libs.LibraryConfiguration>
{code}

Every poll scm poll call finishes like:
Workspace doesn't contain https://svn/ global-library-repo project/data ${library.mylib.version} /legacy/path/mylib . Need a new build.


Everything loads just file when i use:
@Library("mylib@/trunk")
import mylib

but the polling bug makes it re-build every poll call.

I use started out using the Legacy SCM api to declare the lib, because the modern scm dropdown is empty , and due to the nice workaround checking out the library to src/library i can't easily switch to the modern SCM api .

The library is checked out just fine in workspace/pipeline@libs/src/mylib , but it looks like the polling is confused due to this.

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 24, 2016, 10:31:01 AM10/24/16
to jenkinsc...@googlegroups.com

jglick@cloudbees.com (JIRA)

unread,
Oct 24, 2016, 12:33:01 PM10/24/16
to jenkinsc...@googlegroups.com

Not enough to reproduce. I have no idea what “every poll SCM poll call” refers to. Anyway this clearly does not apply to the “modern” option, which would not support such a remote location anyway. (Whatever you are attempting to accomplish with the “legacy location” I do not really follow, but I am pretty sure it is not supported and not going to be.)

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 25, 2016, 2:14:01 PM10/25/16
to jenkinsc...@googlegroups.com
Anton Lundin updated an issue
Change By: Anton Lundin
scm poll call finishes like:
Workspace doesn't contain https://svn/project/data${library.mylib.version}/legacy/path/mylib. Need a new build.


Everything loads just file when i use:
@Library("mylib@/trunk")
import mylib

but the polling bug makes it re-build every poll call.

I started out using the Legacy SCM api to declare the lib, because the modern scm dropdown is empty, and due to the nice workaround checking out the library to src/library i can't easily switch to the modern SCM api.


The library is checked out just fine in workspace/pipeline@libs/src/mylib , but it looks like the polling is confused due to this.

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 25, 2016, 2:20:02 PM10/25/16
to jenkinsc...@googlegroups.com
Anton Lundin commented on Bug JENKINS-38679
 
Re: Polling using legacy SCM fails: “Workspace doesn't contain https://svn/global-library-repo${library.myib.version}”

Sorry for the simpe typo. What i ment was “every SCM poll call”. Or don't you know what scm polling is?

Anyhow, if you're not planning to support the "Legacy SCM api" I'd suggest you completly remove the support for it, so others don't need to waste their time trying to get workflow-cps-global-lib-plugin working with it.

Anyhow, i've solved my problems with the pipeline-classpath plugin instead. Not as pretty, but it works, way better.

jglick@cloudbees.com (JIRA)

unread,
Oct 25, 2016, 2:48:02 PM10/25/16
to jenkinsc...@googlegroups.com

Legacy SCM is supported. The “legacy place in Subversion” sounds dubious.

Yes I know what SCM polling is, but not what it has to do with this issue. Shared libraries do not participate in polling.

Do not what pipeline-classpath is but it is not supported and sounds like a possible security hole.

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 25, 2016, 4:55:05 PM10/25/16
to jenkinsc...@googlegroups.com

Shared libraries do not participate in polling.

, yes, they do and they cause every scm poll call to trigger a build, due to the scm poll function not finding the library in the jobs workspace, so it things its something new and thus a new build is required.

Thats the bug I've reported all a long.

With pipeline-chasspath i referrer to pipeline-classpath-step-plugin, its mentioned under different names in different places. Why are you saying that its a possible security hole?

jglick@cloudbees.com (JIRA)

unread,
Oct 26, 2016, 3:58:01 PM10/26/16
to jenkinsc...@googlegroups.com

be_ray@sbcglobal.net (JIRA)

unread,
Oct 27, 2016, 1:06:04 PM10/27/16
to jenkinsc...@googlegroups.com

be_ray@sbcglobal.net (JIRA)

unread,
Oct 27, 2016, 1:26:01 PM10/27/16
to jenkinsc...@googlegroups.com
Brian Ray commented on Bug JENKINS-38679
 
Re: Polling using legacy SCM fails: “Workspace doesn't contain https://svn/global-library-repo${library.myib.version}”

Jesse Glick, I think I'm experiencing shared libs participating in polling that Anton Lundin is mentioning.

My little test pipeline is using two shared global libs and one folder-specific shared lib; as well as using a polling checkout of the actual project codebase the pipeline is to build. The shared pipeline libs and the project codebase are in SVN servers. I switched over to the Modern Subversion config facility but experienced this at one point with Legacy as well. The pipeline is configured to poll SCM every few hours.

If I'm not mistaken the poll log screenshot

reveals that the shared libs are participating in SCM polling. The first three log messages there are for those libs.

Setup:

LTS 2.19.1 on Win7 Pro
Zulu OpenJDK 1.8.0_102-b14
Pipeline: SCM Step 2.2
Pipeline: Shared Groovy Libraries 2.4
SCM API 1.3
Subversion 2.7.1

I'm wondering if this is somehow related to the business with multiple shared libs you recently submitted a patch for in the course of JENKINS-38517.

be_ray@sbcglobal.net (JIRA)

unread,
Oct 27, 2016, 1:29:02 PM10/27/16
to jenkinsc...@googlegroups.com
Brian Ray edited a comment on Bug JENKINS-38679
[~jglick], I think I'm experiencing shared libs participating in polling that [~glance] is mentioning.

My little test pipeline is using two shared global libs and one folder-specific shared lib; as well as using a polling {{checkout}} of the actual project codebase the pipeline is to build. The shared pipeline libs and the project codebase are in SVN servers. I switched over to the *Modern* Subversion config facility but experienced this at one point with *Legacy* as well. The pipeline is configured to poll SCM every few hours.


If I'm not mistaken the poll log screenshot

!firefox_2016-10-27_10-01-32.png|thumbnail!


reveals that the shared libs are participating in SCM polling. The first three log messages there are for those libs.

Setup:

LTS 2.19.1 on Win7 Pro
Zulu OpenJDK 1.8.0_102-b14
Pipeline: SCM Step 2.2
Pipeline: Shared Groovy Libraries 2.4
SCM API 1.3
Subversion 2.7.1

I'm wondering if this is somehow related to the business with multiple shared libs [you recently submitted a patch for in the course of JENKINS-38517|https://issues.jenkins-ci.org/browse/JENKINS-38517?focusedCommentId=273032&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-273032].

On further thought, that seems like a reach. But I think the shared libs are still getting caught up in the SCM poll.

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 27, 2016, 2:00:02 PM10/27/16
to jenkinsc...@googlegroups.com

Subversion Polling Log

Started on Oct 27, 2016 5:05:23 PM
Received SCM poll call on master for pipeline-trunk on Oct 27, 2016 5:05:23 PM
https://svn/project/data/pipeline-job is at revision 654


Workspace doesn't contain https://svn/global-library-repo$

Unknown macro: {library.ladok3.version}

/legacy/path/mylib. Need a new build.

Received SCM poll call on master for pipeline-trunk on Oct 27, 2016 5:05:23 PM
https://svn/project is at revision 877
Ignored revision 877: Found no included paths
Done. Took 0.2 sec
Changes found

So, pipeline code haven't changed, The code haven't changed, but because it can't find the library in the workspace, it triggers a build.

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 27, 2016, 2:01:01 PM10/27/16
to jenkinsc...@googlegroups.com
Anton Lundin edited a comment on Bug JENKINS-38679
{quote}Subversion Polling Log


Started on Oct 27, 2016 5:05:23 PM
Received SCM poll call on master for pipeline-trunk on Oct 27, 2016 5:05:23 PM
https://svn/project/data/pipeline-job is at revision 654
Workspace doesn't contain https://svn/global-library-repo \ $ \ {library.ladok3.version \ }/legacy/path/mylib. Need a new build.

Received SCM poll call on master for pipeline-trunk on Oct 27, 2016 5:05:23 PM
https://svn/project is at revision 877
Ignored revision 877: Found no included paths
Done. Took 0.2 sec
Changes found
{quote}


So, pipeline code haven't changed, The code haven't changed, but because it can't find the library in the workspace, it triggers a build.

jglick@cloudbees.com (JIRA)

unread,
Oct 28, 2016, 1:19:01 PM10/28/16
to jenkinsc...@googlegroups.com

Dunno, will have to see if it is reproducible in a functional test when I have some time.

bmarwell@gmail.com (JIRA)

unread,
Mar 13, 2020, 7:21:02 AM3/13/20
to jenkinsc...@googlegroups.com
Ben M commented on Bug JENKINS-38679

The problem is actually that the variable does not get resolved when checking for existence. This is still an issue.

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages