• 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

          avishayh added a comment -

          I've managed to patch this one, it's real easy, only one line of code change

          in Class: hudson.scm.SubversionSCM

          line 377:
          final SVNRevision revision = SVNRevision.create(timestamp);
          replace to:
          final SVNRevision revision = SVNRevision.HEAD;

          avishayh added a comment - I've managed to patch this one, it's real easy, only one line of code change in Class: hudson.scm.SubversionSCM line 377: final SVNRevision revision = SVNRevision.create(timestamp); replace to: final SVNRevision revision = SVNRevision.HEAD;

          avishayh added a comment -

          Created an attachment (id=169)
          The patched source file

          avishayh added a comment - Created an attachment (id=169) The patched source file

              • Issue 1263 has been marked as a duplicate of this issue. ***

          Kohsuke Kawaguchi added a comment - Issue 1263 has been marked as a duplicate of this issue. ***

          avishayh added a comment -

          As for Issue 1481, I agree its necessary sometime to be able to choose the
          Revision Number (or share it between builds), I think all these features should
          be optinal for each build.
          If i want a "HEAD build" or a "TimeStamp based build" I will need to specify it
          on the build itself.

          avishayh added a comment - As for Issue 1481, I agree its necessary sometime to be able to choose the Revision Number (or share it between builds), I think all these features should be optinal for each build. If i want a "HEAD build" or a "TimeStamp based build" I will need to specify it on the build itself.

          imjimmurphy added a comment -

          We've just been bit my this issue. We use a hosted SVN service and that server
          and our build machine time's drifted a few minutes - caused our build to do some
          funky stuff.

          Clearly the HEAD revision approach is the simplest and most deterministic, no? I
          would advocate for not having yet another config option - just change the way
          its done so its more likely to work out of the box.

          imjimmurphy added a comment - We've just been bit my this issue. We use a hosted SVN service and that server and our build machine time's drifted a few minutes - caused our build to do some funky stuff. Clearly the HEAD revision approach is the simplest and most deterministic, no? I would advocate for not having yet another config option - just change the way its done so its more likely to work out of the box.

          mdonohue added a comment -
              • Issue 2136 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 2136 has been marked as a duplicate of this issue. ***

          kutzi added a comment -

          I don't understand either why Hudson doesn't simply use the HEAD revision for checkout. This is the simplest and most error-proof approach IMHO.

          kutzi added a comment - I don't understand either why Hudson doesn't simply use the HEAD revision for checkout. This is the simplest and most error-proof approach IMHO.

          raboof added a comment -

          I appreciate the problem with Matrix Builds and checking out HEAD, but doing this by timestamp has caused us trouble on a couple of occasions when the server clock was off.

          Perhaps updating by timestamp should become optional?

          raboof added a comment - I appreciate the problem with Matrix Builds and checking out HEAD, but doing this by timestamp has caused us trouble on a couple of occasions when the server clock was off. Perhaps updating by timestamp should become optional?

          jobybett added a comment -

          I totally agree, we have a development team in India using SVN thats replicated to the US, where we have our main CI installation, Hudson never checks out to the REAL HEAD as the time difference on the code time stamps causes the revisions to "not exist yet" Surly HEAD should be the default behavior and for matrix jobs it can be overridden?

          jobybett added a comment - I totally agree, we have a development team in India using SVN thats replicated to the US, where we have our main CI installation, Hudson never checks out to the REAL HEAD as the time difference on the code time stamps causes the revisions to "not exist yet" Surly HEAD should be the default behavior and for matrix jobs it can be overridden?

          Dean Yu added a comment -

          Would being able to specify @HEAD in the module location be an acceptable workaround for people?

          Dean Yu added a comment - Would being able to specify @HEAD in the module location be an acceptable workaround for people?

          kutzi added a comment -

          dty, that would be fine for me. But I still think that HEAD should be the default.
          As others have said: why should all job types suffer from the current default, when only Matrix builds have a problem with HEAD?

          kutzi added a comment - dty, that would be fine for me. But I still think that HEAD should be the default. As others have said: why should all job types suffer from the current default, when only Matrix builds have a problem with HEAD?

          Dean Yu added a comment -

          My main concern is backwards compatibility. What the other comments on this bug haven't mentioned is that the timestamp that is used is the timestamp at the time the build is put into the queue. It is not the timestamp of when the checkout happens. So if people are expecting the checkout to approximate the state of the repository at the time the build was triggered, this would change how their builds behave. In particular, installations that tend to have builds queued for a long time before they are assigned to an executor would potentially pick up more changes than might have been intended.

          Another point to consider is that Hudson core needs to work with any SCM, and using a timestamp would seem to be the most portable.

          Having said all that, I don't have a strong opinion one way or the other. The only reason I asked about the @HEAD option is because I added to the plugin to support another use case, and recognized that it could be used to address this issue as well.

          Dean Yu added a comment - My main concern is backwards compatibility. What the other comments on this bug haven't mentioned is that the timestamp that is used is the timestamp at the time the build is put into the queue. It is not the timestamp of when the checkout happens. So if people are expecting the checkout to approximate the state of the repository at the time the build was triggered, this would change how their builds behave. In particular, installations that tend to have builds queued for a long time before they are assigned to an executor would potentially pick up more changes than might have been intended. Another point to consider is that Hudson core needs to work with any SCM, and using a timestamp would seem to be the most portable. Having said all that, I don't have a strong opinion one way or the other. The only reason I asked about the @HEAD option is because I added to the plugin to support another use case, and recognized that it could be used to address this issue as well.

          jobybett added a comment -

          @HEAD is a workable solution for me too, I tend to agree with Kutzi, but given the issues this is causing us, I'll take anything that works

          jobybett added a comment - @HEAD is a workable solution for me too, I tend to agree with Kutzi, but given the issues this is causing us, I'll take anything that works

          kutzi added a comment -

          > What the other comments on this bug haven't mentioned is that the timestamp that is used is the timestamp at the time the build is put into the queue. It is not the timestamp of when the checkout happens.

          Woah, that's even worse than I thought (and explains some 'strange' builds which I've seen, which didn't pick up all the changes).
          My intuition would have been that it should take the timestamp of when the build is actually started.

          Speaking about the options about what should be checked out, I think that there are 3 of them:

          I) use latest from repository (i.e. HEAD for SVN)

          IMHO the most senseful default for almost all job type

          II) use state as of a given timestamp

          Probably only useful for matrix jobs

          III) build a specific revision

          Maybe also usable for matrix jobs. Otherwise useful for post-commit hooks which should trigger a build for this specific revision

          Most SCMs I know of should be able to implement all 3 of these options (with the exception of CVS which AFAIR doesn't have a global revision)

          kutzi added a comment - > What the other comments on this bug haven't mentioned is that the timestamp that is used is the timestamp at the time the build is put into the queue. It is not the timestamp of when the checkout happens. Woah, that's even worse than I thought (and explains some 'strange' builds which I've seen, which didn't pick up all the changes). My intuition would have been that it should take the timestamp of when the build is actually started. Speaking about the options about what should be checked out, I think that there are 3 of them: I) use latest from repository (i.e. HEAD for SVN) IMHO the most senseful default for almost all job type II) use state as of a given timestamp Probably only useful for matrix jobs III) build a specific revision Maybe also usable for matrix jobs. Otherwise useful for post-commit hooks which should trigger a build for this specific revision Most SCMs I know of should be able to implement all 3 of these options (with the exception of CVS which AFAIR doesn't have a global revision)

          kutzi added a comment -

          Seems like @HEAD is supported in URLs since subversion plugin 1.22

          kutzi added a comment - Seems like @HEAD is supported in URLs since subversion plugin 1.22

          tonylampada2 added a comment -

          I think the best solution would be creating a global configuration parameter on "Manage Hudson" that sets the default SCM checkout/update.

          Something like:

          SCM revision policy:

          • Option 1: by timestamp (queueing time) - Factory default
          • Option 2: by timestamp (build time)
          • Option 3: Just do what everyone expects and use the HEAD for god sakes.

          Come on, everyone wants it.
          Pretty please?

          tonylampada2 added a comment - I think the best solution would be creating a global configuration parameter on "Manage Hudson" that sets the default SCM checkout/update. Something like: SCM revision policy : Option 1: by timestamp (queueing time) - Factory default Option 2: by timestamp (build time) Option 3: Just do what everyone expects and use the HEAD for god sakes. Come on, everyone wants it. Pretty please?

          sstock added a comment -

          I think any job configured with multiple Subversion paths would need to use a timestamp based method. Otherwise you'd run the risk of discrepancies as subsequent module checkouts/updates could contain changes committed after the earlier Subversion paths had been pulled. Problems would be more frequent with large code bases, WAN links, and/or active projects.

          sstock added a comment - I think any job configured with multiple Subversion paths would need to use a timestamp based method. Otherwise you'd run the risk of discrepancies as subsequent module checkouts/updates could contain changes committed after the earlier Subversion paths had been pulled. Problems would be more frequent with large code bases, WAN links, and/or active projects.

          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: