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

force using HEAD SVN version for build

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: All

      Description

      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.

        Issue Links

          Activity

          Hide
          leedega 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.

          Show
          leedega 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.
          Hide
          leedega 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.

          Show
          leedega 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.
          Hide
          leedega 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.

          Show
          leedega 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.
          Hide
          leedega 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.

          Show
          leedega 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.
          Hide
          rcpao Roger C. Pao added a comment -

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

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

            People

            • Assignee:
              Unassigned
              Reporter:
              avishayh avishayh
            • Votes:
              38 Vote for this issue
              Watchers:
              35 Start watching this issue

              Dates

              • Created:
                Updated: