Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18714

SVN_URL and SVN_REVISION environment variables are missing when repository url contains a variable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • None
    • RHEL5 using Jenkins ver. 1.522 with Subversion Plug-in 1.50

      When you use a repository url that contains a variable such as https://mysvn/apps/myapp/${SVN_MYAPP_BRANCH} it does not set the SVN_URL and SVN_REVISION variables. If it is set to a non variable https://mysvn/apps/myapp/trunk it works.

          [JENKINS-18714] SVN_URL and SVN_REVISION environment variables are missing when repository url contains a variable

          My environment:
          Jenkins 1.525
          Jenkins Subversion Plug-in 1.50 but problem was also with version 1.44

          Damian Klimowicz added a comment - My environment: Jenkins 1.525 Jenkins Subversion Plug-in 1.50 but problem was also with version 1.44

          I am seeing this same behavior. When the definition of the "Repository URL" includes a variable, the checkout works but the SVN_REVISION and SVN_URL variables no longer get set after the checkout.

          I know the URL – I can get that from the same environment variable used to do the checkout. But it would be nice to get the revision number for build tracking.

          As the original poster said, when I specify the URL explicitly it works fine. But in may case, I want to copy jobs from one branch to another and have them run identically. So I do the copy and fill in the branch name in the SVN URL by taking part of the job title. Works fine except I lose the SVN_REVISION and SVN_URL variables from the plugin.

          Karl DeBisschop added a comment - I am seeing this same behavior. When the definition of the "Repository URL" includes a variable, the checkout works but the SVN_REVISION and SVN_URL variables no longer get set after the checkout. I know the URL – I can get that from the same environment variable used to do the checkout. But it would be nice to get the revision number for build tracking. As the original poster said, when I specify the URL explicitly it works fine. But in may case, I want to copy jobs from one branch to another and have them run identically. So I do the copy and fill in the branch name in the SVN URL by taking part of the job title. Works fine except I lose the SVN_REVISION and SVN_URL variables from the plugin.

          Daniel Beck added a comment -

          I've looked into this a few months ago, and this is what I found:

          The problem is that AbstractBuild queries (in that order) EnvironmentContributors, SCM, BuildWrapper.Environments and EnvironmentContributingActions to incrementally build the set of environment variables while a build is started.

          SubversionSCM (an SCM) looks for matching entries in the URL -> Revision map during this variable resolution. If so, they are added as SVN_URL_x and SVN_REVISION_x. Why not just add everything? My guess is externals (while listed for a build, only explicitly defined locations have corresponding variables).

          Due to the order of resolution, Env-Injected variables are not yet defined. This leads to a warning in the log of the form:

          WARNING hudson.scm.SubversionSCM buildEnvVars
          no revision found corresponding to ${SVNURL}; known: [https://svn/repo/...]

          Afterwards, when the URLs are getting checked out, the variables have already been defined, therefore that works.

          Daniel Beck added a comment - I've looked into this a few months ago, and this is what I found: The problem is that AbstractBuild queries (in that order) EnvironmentContributors, SCM, BuildWrapper.Environments and EnvironmentContributingActions to incrementally build the set of environment variables while a build is started. SubversionSCM (an SCM) looks for matching entries in the URL -> Revision map during this variable resolution. If so, they are added as SVN_URL_x and SVN_REVISION_x. Why not just add everything? My guess is externals (while listed for a build, only explicitly defined locations have corresponding variables). Due to the order of resolution, Env-Injected variables are not yet defined. This leads to a warning in the log of the form: WARNING hudson.scm.SubversionSCM buildEnvVars no revision found corresponding to ${SVNURL}; known: [https://svn/repo/...] Afterwards, when the URLs are getting checked out, the variables have already been defined, therefore that works.

          danielbeck I'm going to try to reproduce this bug using the latest versions of Subversion Plugin and EnvInject.

          Manuel Recena Soto added a comment - danielbeck I'm going to try to reproduce this bug using the latest versions of Subversion Plugin and EnvInject.

          Could anybody confirm if this bug is still there using Subversion Plugin 2.5.3 and EnvInject Plugin 1.92.1?

          Manuel Recena Soto added a comment - Could anybody confirm if this bug is still there using Subversion Plugin 2.5.3 and EnvInject Plugin 1.92.1 ?

          I can not reproduce this bug.

          lcasey, Could you provide any feedback?

          Manuel Recena Soto added a comment - I can not reproduce this bug. lcasey , Could you provide any feedback?

          Slawomir Czarko added a comment - - edited

          Still happens with Subversion Plugin 2.5.3 and EnvInject Plugin 1.92.1

          I take it back. I had a problem yesterday with missing SVN_URL and SVN_REVISION variables but it had nothing to do with this bug. The problem was in my scripts.

          Slawomir Czarko added a comment - - edited Still happens with Subversion Plugin 2.5.3 and EnvInject Plugin 1.92.1 I take it back. I had a problem yesterday with missing SVN_URL and SVN_REVISION variables but it had nothing to do with this bug. The problem was in my scripts.

          Manuel Recena Soto added a comment - - edited

          slawomir_czarko I tried to reproduce the bug unsuccessful.

          I really want to help here but I need a step by step so that can reproduce the bug and find a solution.

          Manuel Recena Soto added a comment - - edited slawomir_czarko I tried to reproduce the bug unsuccessful. I really want to help here but I need a step by step so that can reproduce the bug and find a solution.

          @Slawomir Czarko Thank you for your feedback.

          Manuel Recena Soto added a comment - @Slawomir Czarko Thank you for your feedback.

          This bug seems to be solved in recent versions of Subversion Plugin.

          Manuel Recena Soto added a comment - This bug seems to be solved in recent versions of Subversion Plugin.

            recena Manuel Recena Soto
            lcasey Luiz Casey
            Votes:
            7 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: