• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      the svn pooling is using a Date based decision to update/checkout from SVN,
      instead of using the HEAD revision.

      We need to be able to chhose for a build that he must use HEAD.

          [JENKINS-1241] force using HEAD SVN version for build

          kutzi added a comment -

          @sstock: good point. However, this will also only work, if ALL subversion servers included will have their times exactly synchronized.

          In case all paths show to the same repository, a revision based check out should also work.

          kutzi added a comment - @sstock: good point. However, this will also only work, if ALL subversion servers included will have their times exactly synchronized. In case all paths show to the same repository, a revision based check out should also work.

          Anne Stellingwerf added a comment - - edited

          Is there any workaround to set the revision in the BuildWrapper.preCheckout?

          Updated:
          Can be worked around by using build.addAction(new RevisionParameterAction(...)), and providing SvnInfo instances for all Module URLs.

          Anne Stellingwerf added a comment - - edited Is there any workaround to set the revision in the BuildWrapper.preCheckout? Updated: Can be worked around by using build.addAction(new RevisionParameterAction(...)), and providing SvnInfo instances for all Module URLs.

          Y Lefebvre added a comment -

          We got burned by this issue today. Our releases are always based on Tag version of projects. Our Jenkins server time has drifted so we got problems.

          We commited some fix in head and do a tag branch with svn. Next, we do a build of the tag with Jenkins. It turn out it checkout older files. One could have think that checking out file from a branch or tag path would give the correct files, but you can get files older than the tag itself...

          In case you always build from svn tags, it doesn't make sense to have timestamp used by the build process if tags folder are managed correctly by the users (no commit of file in a tag folder).

          Y Lefebvre added a comment - We got burned by this issue today. Our releases are always based on Tag version of projects. Our Jenkins server time has drifted so we got problems. We commited some fix in head and do a tag branch with svn. Next, we do a build of the tag with Jenkins. It turn out it checkout older files. One could have think that checking out file from a branch or tag path would give the correct files, but you can get files older than the tag itself... In case you always build from svn tags, it doesn't make sense to have timestamp used by the build process if tags folder are managed correctly by the users (no commit of file in a tag folder).

          Greg Hansen added a comment -

          I like tonylampada2's solution. I have several independent builds that I'd like to all use the same revision so they are consistent (the builds are for different products, but all products would like to use the same revision of the underlying code). I tried putting in a pre-SCM-checkout step to set a variable from a web service, but the SVN checkout did not pick up the change in the value of the variable. I tried making the build parameterized, and triggering it from a prior build that set the parameter from the web service, but the value doesn't get passed (yes, I checked that the environment should pass in). I tried not having parameters, which also failed.

          Does anyone know how to set a parameter to that will be passed to the SVN plugin from an external source?

          Greg Hansen added a comment - I like tonylampada2's solution. I have several independent builds that I'd like to all use the same revision so they are consistent (the builds are for different products, but all products would like to use the same revision of the underlying code). I tried putting in a pre-SCM-checkout step to set a variable from a web service, but the SVN checkout did not pick up the change in the value of the variable. I tried making the build parameterized, and triggering it from a prior build that set the parameter from the web service, but the value doesn't get passed (yes, I checked that the environment should pass in). I tried not having parameters, which also failed. Does anyone know how to set a parameter to that will be passed to the SVN plugin from an external source?

          @Greg Hansen
          Out of the box you can use the Parameterized Trigger Plugin to pass an SVN revision number from one job to the next. The specifics on how this works aren't clearly stated on the plugin wiki unfortunately, and this configuration does have a few limitations - most notably, that all of your job configurations must share the same source / SVN URL. If this is a non issue for you then you may want to start there.

          Otherwise, one thing you could try is define a custom property (ie: using the Parameterized Build Plugin) which will contain the SVN revision number, and then reference the property in your SVN configuration area in your job, something like "http://path_to_repo/project@${MY_NEW_PROPERTY}". This should force subsequent checkout operations to always check out using the given revision. You can also leverage the parameterized trigger plugin to pass revisions between projects in this way as well.

          Kevin Phillips added a comment - @Greg Hansen Out of the box you can use the Parameterized Trigger Plugin to pass an SVN revision number from one job to the next. The specifics on how this works aren't clearly stated on the plugin wiki unfortunately, and this configuration does have a few limitations - most notably, that all of your job configurations must share the same source / SVN URL. If this is a non issue for you then you may want to start there. Otherwise, one thing you could try is define a custom property (ie: using the Parameterized Build Plugin ) which will contain the SVN revision number, and then reference the property in your SVN configuration area in your job, something like "http://path_to_repo/project@${MY_NEW_PROPERTY}". This should force subsequent checkout operations to always check out using the given revision. You can also leverage the parameterized trigger plugin to pass revisions between projects in this way as well.

          @tonylampada2
          I like your suggestion. However, to help isolate the impact of such configuration options it may be safer to provide them at the job level rather than in the global Jenkins configuration.

          Also, I think there could be a 4th option as well: by revision. For example, if someone uses a single repository for all their projects, there is one global revision number shared across all projects and this revision number is guaranteed to be unique. Therefore, building by revision is effectively the same as build by timestamp and yet it avoids the problem of clock skew.

          Kevin Phillips added a comment - @tonylampada2 I like your suggestion. However, to help isolate the impact of such configuration options it may be safer to provide them at the job level rather than in the global Jenkins configuration. Also, I think there could be a 4th option as well: by revision. For example, if someone uses a single repository for all their projects, there is one global revision number shared across all projects and this revision number is guaranteed to be unique. Therefore, building by revision is effectively the same as build by timestamp and yet it avoids the problem of clock skew.

          Kevin Phillips added a comment - - edited

          @Dean Yu here

          Using @HEAD achieves the desired result of ensuring a checkout always grabs the latest revision, however the current SVN plugin has one glaring flaw with this - the "HEAD" revision number is not assigned to the Jenkins SVN_REVISION property / environment variable. Consequently you end up in a situation where your checkout is done at a certain revision and that revision is not easily addressable / referenced elsewhere in the project (e.g.: in the build label, for example). Similarly this makes it difficult, if not impossible, to propagate the same revision number to downstream jobs. Sure, you can configure the downstream jobs to use @HEAD as well, but this prevents you from ensuring a set of jobs runs against the same revision number.

          Put another way, using this workaround is incompatible with the Parameterized Trigger Plugin because the revision number that gets propagated to downstream jobs is incorrect.

          Amendment
          Also, I just exploited another bug with this pattern. Since the SVN plugin triggers from a time stamp, you end up with redundant executions of jobs using this pattern. The use case goes something like this:

          1. Commit a change to the repo
          2. Wait until the Jenkins job triggers
          3. While the job is waiting in queue, commit another change to the same project
          4. A second instance of the job now enters the queue
          5. when the first instance of the job begins, it will update to the head revision, grabbing both changes
          6. when the second instance of the job begins, it looks at the current checkout and sees no changes (because there are none) but the build is still executed

          Luckily the revision logs associated with the first execution does appear to show both change sets, so at least that information is consistent.

          Kevin Phillips added a comment - - edited @Dean Yu here Using @HEAD achieves the desired result of ensuring a checkout always grabs the latest revision, however the current SVN plugin has one glaring flaw with this - the "HEAD" revision number is not assigned to the Jenkins SVN_REVISION property / environment variable. Consequently you end up in a situation where your checkout is done at a certain revision and that revision is not easily addressable / referenced elsewhere in the project (e.g.: in the build label, for example). Similarly this makes it difficult, if not impossible, to propagate the same revision number to downstream jobs. Sure, you can configure the downstream jobs to use @HEAD as well, but this prevents you from ensuring a set of jobs runs against the same revision number. Put another way, using this workaround is incompatible with the Parameterized Trigger Plugin because the revision number that gets propagated to downstream jobs is incorrect. Amendment Also, I just exploited another bug with this pattern. Since the SVN plugin triggers from a time stamp, you end up with redundant executions of jobs using this pattern. The use case goes something like this: Commit a change to the repo Wait until the Jenkins job triggers While the job is waiting in queue, commit another change to the same project A second instance of the job now enters the queue when the first instance of the job begins, it will update to the head revision, grabbing both changes when the second instance of the job begins, it looks at the current checkout and sees no changes (because there are none) but the build is still executed Luckily the revision logs associated with the first execution does appear to show both change sets, so at least that information is consistent.

          Kevin Phillips added a comment - - edited

          I just recently exploited yet another SVN revision number bug that is kind of tangientially related to this one.

          Correction - I've added a new enhancement request for the SVN plugin that may partially circumvent some of the use cases people are discussing here. See JENKINS-18907 for details.

          Kevin Phillips added a comment - - edited I just recently exploited yet another SVN revision number bug that is kind of tangientially related to this one. Correction - I've added a new enhancement request for the SVN plugin that may partially circumvent some of the use cases people are discussing here. See JENKINS-18907 for details.

          NOTE
          Upon further review, I think the failure condition I was describing in my earlier comment may in fact be indicative of the different SVN revision numbers available in a typical working folder (e.g.: last change revision vs latest revision). As such if the other improvement request I recently created were to be implemented this problem may be avoidable. By leveraging the "latest revision" instead of the "last change revision" the @HEAD "workaround" mentioned here just may work.

          Kevin Phillips added a comment - NOTE Upon further review, I think the failure condition I was describing in my earlier comment may in fact be indicative of the different SVN revision numbers available in a typical working folder (e.g.: last change revision vs latest revision). As such if the other improvement request I recently created were to be implemented this problem may be avoidable. By leveraging the "latest revision" instead of the "last change revision" the @HEAD "workaround" mentioned here just may work.

          Roger C. Pao added a comment -

          If svn:externals are used, the revision checked out will be the Last Changed Rev and not HEAD.

          Roger C. Pao added a comment - If svn:externals are used, the revision checked out will be the Last Changed Rev and not HEAD.

            Unassigned Unassigned
            avishayh avishayh
            Votes:
            41 Vote for this issue
            Watchers:
            38 Start watching this issue

              Created:
              Updated: