[JENKINS-38679] Constant builds when svn url contains parameter

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:

    

      mylib

      "org.jenkinsci.plugins.workflow.libs.SCMRetriever">

"hudson.scm.SubversionSCM" plugin="subversion@​2.7.1">

  

    

      https://svn/project/data${library.ladok3.version}/legacy/path/mylib

      xxx

      src/mylib

      infinity

      true

    

  

  /.*

  

  

  

  

  "hudson.scm.subversion.UpdateUpdater"/>

  false

  false


      

      /trunk

      false

      true

    

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

---
Originally reported by glance, imported from: Constant builds when svn url contains parameter

• status: Open
  
• priority: Major
  
• component(s): subversion-plugin, workflow-cps-global-lib-plugin
  
• resolution: Unresolved
  
• votes: 5
  
• watchers: 10
  
• imported: 20251212-090250
  

Raw content of original 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:




    <org.jenkinsci.plugins.workflow.libs.LibraryConfiguration>

      <name>mylib</name>

      <retriever class="org.jenkinsci.plugins.workflow.libs.SCMRetriever">

        <scm class="hudson.scm.SubversionSCM" plugin="subversion@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>





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

1 attachment

- [firefox_2016-10-27_10-01-32.png](https://issues.jenkins.io/secure/attachment/34615/firefox_2016-10-27_10-01-32.png)
>