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

Triggered project is not built with the same svn revision as the project which triggered it

      This is our rough configuration:

      Project U (upstream):

      • Is a matrix project
      • Runs on multiple platforms to create released files for each platform.
        These put the subversion revision number inside various files.
      • Archives artifacts back to Jenkins
      • Triggers parameterised build on D, passing only the Subversion revision

      Project D (downstream):

      • Is not a matrix project
      • Checks out a small subset of the code as required to do its work.
      • Uses the subversion revision number to decide where to copy the merged results.

      I'm finding that despite setting up the parameterised trigger, the Subversion revision it's checking out does not match.

      Logs from U show it checking out revision 32983:

      00:00:00.000 Started by user user
      00:00:00.004 Building remotely on Igor in workspace h:\hudson\workspace\platform-releases
      00:00:00.127 Cleaning up h:\hudson\workspace\platform-releases\product
      00:00:30.427 Updating https://svn/acme/trunk/product at revision '2014-01-31T13:28:23.587 +1100'
      [... omitting files ...]
      00:00:44.026 At revision 32983
      00:00:44.307 Triggering windows
      00:00:44.310 Triggering macosx
      00:43:52.585 Triggering a new build of unified-releases #53
      00:43:52.789 Finished: SUCCESS
      

      Logs from D show it checking out a mix of revisions, which is what you normally get if you're checking out bits and pieces of the repository:

      00:00:00.000 Started by upstream project "platform-releases" build number 70
      00:00:00.002 originally caused by:
      00:00:00.002  Started by user user
      00:00:00.012 Building remotely on Sebastian in workspace h:\hudson\workspace\unified-releases
      00:00:00.193 Reverting h:\hudson\workspace\unified-releases\product to depth immediates with ignoreExternals: false
      00:00:03.365 Updating https://svn/acme/trunk/product at revision 32983
      [... omitting files ...]
      00:00:20.211 At revision 32983
      00:00:20.432 Reverting h:\hudson\workspace\unified-releases\product\release to depth infinity with ignoreExternals: false
      00:00:21.365 Updating https://svn/acme/trunk/product/release at revision '2014-01-31T14:12:22.103 +1100'
      [... omitting files ...]
      00:01:48.591 At revision 32989
      00:01:49.586 no change for https://svn/acme/trunk/product/release since the previous build
      

      It looks like the top-level directory revision matches revision numbers, but the directories further in do not. The timestamps do not match at any point, either.

      I would expect all the revision numbers and timestamps of revisions to match between the two builds.

          [JENKINS-21586] Triggered project is not built with the same svn revision as the project which triggered it

          ikedam added a comment -

          The problem looks that, revisions of the root directory and the sub directory does not match in the downstream project.

          I'm not sure it is correct behavior of subversion to checkout an inconsistent repository tree.
          It may be a issue of subversion-plugin rather than parameterized-trigger-plugin.

          Do you use svn:external?

          ikedam added a comment - The problem looks that, revisions of the root directory and the sub directory does not match in the downstream project. I'm not sure it is correct behavior of subversion to checkout an inconsistent repository tree. It may be a issue of subversion-plugin rather than parameterized-trigger-plugin. Do you use svn:external?

          trejkaz added a comment -

          Not using svn:externals, no. Just checking out the root dir and then checking out a subdirectory of it into a subdirectory.

          trejkaz added a comment - Not using svn:externals, no. Just checking out the root dir and then checking out a subdirectory of it into a subdirectory.

          ikedam added a comment -

          It seems that the subversion revision passed by parameterized-trigger-plugin affects the revision only of repositories with the exactly same url.
          So the revision for /trunk/product does not work for /trunk/product/release.

          This is a limitation of subversion-plugin rather than that of parameterized-trigger-plugin.

          ikedam added a comment - It seems that the subversion revision passed by parameterized-trigger-plugin affects the revision only of repositories with the exactly same url. So the revision for /trunk/product does not work for /trunk/product/release. This is a limitation of subversion-plugin rather than that of parameterized-trigger-plugin.

          trejkaz added a comment -

          Rats. So my options are to either check out the whole repository and live with the time and disk space penalty, or report something to subversion-plugin to make it possible to either check out a sub-URL with the same revision, or to choose which directories get checked out for the top URL.

          trejkaz added a comment - Rats. So my options are to either check out the whole repository and live with the time and disk space penalty, or report something to subversion-plugin to make it possible to either check out a sub-URL with the same revision, or to choose which directories get checked out for the top URL.

          ikedam added a comment -

          How about check out /trunk/product/release by calling svn command from shell script builder?
          The revision to check out can be determined from /trunk/product checked out by subversion plugin.

          ikedam added a comment - How about check out /trunk/product/release by calling svn command from shell script builder? The revision to check out can be determined from /trunk/product checked out by subversion plugin.

          trejkaz added a comment -

          I am considering that option as well. The complication is that we'd have to make sure an svn client is on every build environment, whereas at the moment we are relying on Jenkins' internal one to do the job.

          trejkaz added a comment - I am considering that option as well. The complication is that we'd have to make sure an svn client is on every build environment, whereas at the moment we are relying on Jenkins' internal one to do the job.

          ikedam added a comment -

          Instead of using "Subversion revision", you can do as following:

          • Use "Predefined parameters" and write like this:
            UPSTREAM_SVN_REVISION=${SVN_REVISION}
            
          • Configure following two Subversion in Project D:
            • .../trunk/product@${UPSTREAM_SVN_REVISION}
            • .../trunk/product/release@${UPSTREAM_SVN_REVISION}

          You can specify revision to check out with repositoryurl@${revision}.
          But I don't know well how it works, so you should test it carefully.

          ikedam added a comment - Instead of using "Subversion revision", you can do as following: Use "Predefined parameters" and write like this: UPSTREAM_SVN_REVISION=${SVN_REVISION} Configure following two Subversion in Project D: .../trunk/product@${UPSTREAM_SVN_REVISION} .../trunk/product/release@${UPSTREAM_SVN_REVISION} You can specify revision to check out with repositoryurl@${revision}. But I don't know well how it works, so you should test it carefully.

            ikedam ikedam
            trejkaz trejkaz
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: