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

Possible inconsistent checkouts if using multiple modules and post-commit-hook resp. RevisionParameter

    Details

    • Similar Issues:

      Description

      We have a job with a lot of SVN modules configured (most of them point in fact to the same repository, but different paths in it) and the SVN post-commit-hook configured as described in the Wiki https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin#SubversionPlugin-Postcommithook

      What we experienced by this was that we had often inconsistent checkouts - i.e. some modules having an older revision than others, though they are from the same repository. We had this on nearly every 3rd build!

      We thought that Jenkins was always checking out based on the timestamp of the build to ensure consistent revision across all modules, however this turned out to be only partly true. What turned out to be the problem, is the ?rev=$REV parameter in the post-commit-hook which 'fixes' the modules (via RevisionParameterAction) which are triggered by this hook to be on that revision. In case some other changes come on to this module or other modules between starting the build and checking out the module, this lead to inconsistent checkouts as the other modules (not triggered explicitly) are checked-out based on timestamp.

      The workaround in this case was quite simple: remove ?rev=$REV from the post-commit-hook. However, I think this points out a general problem when working with post-commit-hook/RevisionParameters and multiple modules.

        Attachments

          Activity

          Hide
          kutzi kutzi added a comment -

          Not sure how to fix this, but the description in the wiki should be adapted to remove ?rev=$REV from the example or at least issue a warning that it can lead to problems with multiple modules.
          Also we could issue a warning in the build log if a job has multiple modules AND more than one of those have SVN changes AND only SOME of them have a revisionparameter specified.

          For a general solution on how to ensure consistent checkouts, if only some modules have revisionparameter: I think that would be very difficult.

          Show
          kutzi kutzi added a comment - Not sure how to fix this, but the description in the wiki should be adapted to remove ?rev=$REV from the example or at least issue a warning that it can lead to problems with multiple modules. Also we could issue a warning in the build log if a job has multiple modules AND more than one of those have SVN changes AND only SOME of them have a revisionparameter specified. For a general solution on how to ensure consistent checkouts, if only some modules have revisionparameter: I think that would be very difficult.
          Hide
          dcendents Daniel Beland added a comment -

          The rev parameter can also cause problems when performing a maven release. I configured jenkins to deploy snapshots in our nexus repository, but jenkins is not allowed to deploy a released artifact.

          With the rev parameter on, jenkins tries to build the intermediate commit during the release, which I personnally don't want. I think this scenario could also be added to the wiki. I didn't pay much attention because my projects only have a single module location.

          Show
          dcendents Daniel Beland added a comment - The rev parameter can also cause problems when performing a maven release. I configured jenkins to deploy snapshots in our nexus repository, but jenkins is not allowed to deploy a released artifact. With the rev parameter on, jenkins tries to build the intermediate commit during the release, which I personnally don't want. I think this scenario could also be added to the wiki. I didn't pay much attention because my projects only have a single module location.
          Hide
          kutzi kutzi added a comment -

          Daniel feel free to add your info to the Wiki!

          Show
          kutzi kutzi added a comment - Daniel feel free to add your info to the Wiki!

            People

            • Assignee:
              kutzi kutzi
              Reporter:
              kutzi kutzi
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: