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

Fail build when subversion workspace is locked

      This is a request to backport a Hudson fix into Jenkins. This is a 2-line change done in Hudson Subversion plugin 2.3.3, SHA 37ca9c134702878e6bb824dde108d63c6df043d8

      https://github.com/hudson-plugins/subversion-plugin/commit/37ca9c134702878e6bb824dde108d63c6df043d8

      Rationale: subversion workspace often remains locked if previous svn update failed because of bad network connection, wiping the workspace is not useful for anything in this situation, rather the opposite.

          [JENKINS-17228] Fail build when subversion workspace is locked

          Paavo Helde created issue -

          jan_ruzicka added a comment -

          current location of the fixed section in
          jenkinsci/subversion-plugin
          is
          src/main/java/hudson/scm/subversion/UpdateUpdater.java
          lines
          181 and 182

          jan_ruzicka added a comment - current location of the fixed section in jenkinsci/subversion-plugin is src/main/java/hudson/scm/subversion/UpdateUpdater.java lines 181 and 182

          jan_ruzicka added a comment -

          Will the failing build unlock the workspace?
          or will all the fallowing builds fail?

          jan_ruzicka added a comment - Will the failing build unlock the workspace? or will all the fallowing builds fail?

          Paavo Helde added a comment -

          In principle the workspace might also be locked because somebody else has logged into the slave computer and doing some svn operations manually. Therefore I would not suggest automatic "svn cleanup" or something like that, just failing the build (as the Hudson fix does) would be fine IMO. A user can always wipe the workspace explicitly if he/she is not able to solve the problem otherwise.

          Paavo Helde added a comment - In principle the workspace might also be locked because somebody else has logged into the slave computer and doing some svn operations manually. Therefore I would not suggest automatic "svn cleanup" or something like that, just failing the build (as the Hudson fix does) would be fine IMO. A user can always wipe the workspace explicitly if he/she is not able to solve the problem otherwise.

          John Elliot added a comment -

          I'd strongly request this fix too.

          We have very large repositories and a full rebuild takes many hours. I would much rather have a chance to fix a repository manually than have jenkins go away and delete the folder.

          The build should just keep failing until the lock is fixed manually.

          John Elliot added a comment - I'd strongly request this fix too. We have very large repositories and a full rebuild takes many hours. I would much rather have a chance to fix a repository manually than have jenkins go away and delete the folder. The build should just keep failing until the lock is fixed manually.

          jan_ruzicka added a comment -

          jan_ruzicka added a comment - the Hudson commit moved around https://github.com/hudson3-plugins/subversion-plugin/commit/37ca9c134702878e6bb824dde108d63c6df043d8
          david etkins made changes -
          Fix Version/s New: current [ 10162 ]
          Due Date New: 2014-02-07
          Issue Type Original: Improvement [ 4 ] New: Bug [ 1 ]

          david etkins added a comment -

          this is not an improvement this is a bug, and it should be fixed ASAP

          david etkins added a comment - this is not an improvement this is a bug, and it should be fixed ASAP

          Greg Roper added a comment -

          Any plans to get this scheduled? Maybe give the user the option to check out a new workspace if the workspace is locked rather than defaulting to it? I'd much rather my build to fail, I can clean up the workspace myself in a few minutes and not have to wait hours for fresh workspace to be built.

          Greg Roper added a comment - Any plans to get this scheduled? Maybe give the user the option to check out a new workspace if the workspace is locked rather than defaulting to it? I'd much rather my build to fail, I can clean up the workspace myself in a few minutes and not have to wait hours for fresh workspace to be built.

          Tim Bradt added a comment -

          Perhaps I'm not understanding this issue correctly. It seems to me that you want the Jenkins job/build to immediately fail if the subversion workspace is locked. I'm confused as to why this is an open issue as that is exactly the behavior I'm seeing with Subversion Plug-in v2.5. For me, this is undesirable due to the structure of our repository. I have multiple builds trying to update their individual portions of the working copy. Unfortunately, svn locks the working copy one directory above the one I'm trying to update, so I get failures if multiple builds are triggered concurrently, even though they are in different sections of the repository. The way it currently works, I'm notifying commiters that they have a build failure even though the changes themselves did not cause the failure, and then if they have nothing more to commit there is no choice but to MANUALLY trigger the job again. Blech.

          I would prefer to have this be configurable. Let me decide if I want it to fail (as it sounds like is the desire here), or try again every ___ seconds with ___ total attempts. This would solve my problem without the other alternatives that I am currently limited to, all of which are fairly drastic and complex.

          So far I'm not finding another issue with that request so will probably submit it.

          Tim Bradt added a comment - Perhaps I'm not understanding this issue correctly. It seems to me that you want the Jenkins job/build to immediately fail if the subversion workspace is locked. I'm confused as to why this is an open issue as that is exactly the behavior I'm seeing with Subversion Plug-in v2.5. For me, this is undesirable due to the structure of our repository. I have multiple builds trying to update their individual portions of the working copy. Unfortunately, svn locks the working copy one directory above the one I'm trying to update, so I get failures if multiple builds are triggered concurrently, even though they are in different sections of the repository. The way it currently works, I'm notifying commiters that they have a build failure even though the changes themselves did not cause the failure, and then if they have nothing more to commit there is no choice but to MANUALLY trigger the job again. Blech. I would prefer to have this be configurable. Let me decide if I want it to fail (as it sounds like is the desire here), or try again every ___ seconds with ___ total attempts. This would solve my problem without the other alternatives that I am currently limited to, all of which are fairly drastic and complex. So far I'm not finding another issue with that request so will probably submit it.

            Unassigned Unassigned
            paavo256 Paavo Helde
            Votes:
            20 Vote for this issue
            Watchers:
            21 Start watching this issue

              Created:
              Updated: