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

Change Subversion plugin to allow configuration of different ways to react to working copy locked

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Windows Server 2012 R2
      Jenkins v1.573
      Subversion Plug-in v2.5
      Chrome

      The Jenkins job/build immediately fails if the working copy is locked. For me, this is undesirable due to the structure of our repository. We have multiple builds trying to update their individual portions of the working copy. Unfortunately, svn locks the working copy one directory above the one in which the update occurs, so we get failures if multiple builds are triggered concurrently, even though they are in different sections of the repository. The way it currently works, we are 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.

      I would much prefer to have this be configurable. Let me decide if I want it to fail (current behavior), or try again every ___ seconds with ___ total attempts, other...

          [JENKINS-27898] Change Subversion plugin to allow configuration of different ways to react to working copy locked

          Daniel Beck added a comment -

          As I wrote in JENKINS-17228:

          Sharing workspaces between jobs is essentially an anti-pattern. That said, there are several plugins allowing you to limit parallel execution of jobs, e.g. Throttle Concurrent Builds Plugin, which will prevent this issue in your situation.

          Hence IMO this request does not make any sense, as it does not appear to be a sensible use case.

          Daniel Beck added a comment - As I wrote in JENKINS-17228 : Sharing workspaces between jobs is essentially an anti-pattern. That said, there are several plugins allowing you to limit parallel execution of jobs, e.g. Throttle Concurrent Builds Plugin, which will prevent this issue in your situation. Hence IMO this request does not make any sense, as it does not appear to be a sensible use case.

          Tim Bradt added a comment -

          These jobs do not actually share workspaces, to be accurate. They each have their own workspace, but within the same working copy of the repository. That is because we have one big repository for our entire suite of software. Inside that repo we have different sections for our different modules that belong to this suite (i.e. - Foundation, Picking, Sorting, Planning, etc). The base URL for the source for these is GII/All/trunk/30-Dev, so my workspaces are at /30-Dev/Foundation, /30-Dev/Picking, /30-Dev/Sorting, etc... So even though I may only be updating the portion of the working copy at 30-Dev/Picking, SVN locks the working copy up at 30-Dev. Thus, I cannot update 30-Dev/Sorting while my Picking job is updating. There are interdependencies between the aforementioned modules (primarily on Foundation) that would make it difficult to break away from a shared working copy. Basically, this repository was designed to simplify developers lives.

          Yes, this is less than ideal (I would love to have individual repositories as we did in Gen 1 of our software), but we are dealing with the constraints given to us. It presents some challenges in a build environment, but the head architect decided to go this direction as it makes a ton of sense for the application side of the business who are actually customizing our product and implementing it for our customers. It may appear to lack sense to someone from the outside looking in with no knowledge of our business model, but it's the hand we've been dealt.

          Throttle Concurrent Builds Plugin really does not provide what I'm after, any more than what I could achieve with limiting executors, though it would simplify that approach. That would queue up my other jobs, which is counter-productive to fast feedback for builds triggered by commits. I don't want to throttle at the job level. I simply want the ability to wait during the svn update portion of these jobs.

          We may look at building our own custom plugin for svn updates if this does not make sense to the core community. I would like to have a plugin that is flexible enough to deal with our business constraints, but if that can't happen then I suppose it's time to start creating our own.

          Tim Bradt added a comment - These jobs do not actually share workspaces, to be accurate. They each have their own workspace, but within the same working copy of the repository. That is because we have one big repository for our entire suite of software. Inside that repo we have different sections for our different modules that belong to this suite (i.e. - Foundation, Picking, Sorting, Planning, etc). The base URL for the source for these is GII/All/trunk/30-Dev, so my workspaces are at /30-Dev/Foundation, /30-Dev/Picking, /30-Dev/Sorting, etc... So even though I may only be updating the portion of the working copy at 30-Dev/Picking, SVN locks the working copy up at 30-Dev. Thus, I cannot update 30-Dev/Sorting while my Picking job is updating. There are interdependencies between the aforementioned modules (primarily on Foundation) that would make it difficult to break away from a shared working copy. Basically, this repository was designed to simplify developers lives. Yes, this is less than ideal (I would love to have individual repositories as we did in Gen 1 of our software), but we are dealing with the constraints given to us. It presents some challenges in a build environment, but the head architect decided to go this direction as it makes a ton of sense for the application side of the business who are actually customizing our product and implementing it for our customers. It may appear to lack sense to someone from the outside looking in with no knowledge of our business model, but it's the hand we've been dealt. Throttle Concurrent Builds Plugin really does not provide what I'm after, any more than what I could achieve with limiting executors, though it would simplify that approach. That would queue up my other jobs, which is counter-productive to fast feedback for builds triggered by commits. I don't want to throttle at the job level. I simply want the ability to wait during the svn update portion of these jobs. We may look at building our own custom plugin for svn updates if this does not make sense to the core community. I would like to have a plugin that is flexible enough to deal with our business constraints, but if that can't happen then I suppose it's time to start creating our own.

            Unassigned Unassigned
            tpbradt Tim Bradt
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: