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

multiple parallel parameterized builds seem to happen at once

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Blocker Blocker
    • core
    • None
    • Platform: All, OS: All

      Currently Hudson does not allow multiple builds in parallel for the same
      project. However when a project is parameterized, this IS possible.

      This is very dangerous, since it's perfectly possible that two builds will be
      started on the same workspace. Imagine your workspace being updated by one build
      while the other one is still doing the build. You might not even notice
      something wrong has happened but your build results would be completely bogus.

      The current workaround is to make sure you do only one parallel build per node.

      The immediate solution is to disable parallel builds in the core, but this
      requires implementing equals() and hashcode() differently on ALL Queue.Task
      implementers.

      The final solution is to implement decent locking, and fix all other places in
      Hudson that depend on only having one build running.

          [JENKINS-2997] multiple parallel parameterized builds seem to happen at once

          Alan Harder added a comment -

          can you provide steps to see this problem from a clean install of the latest
          hudson release?

          Alan Harder added a comment - can you provide steps to see this problem from a clean install of the latest hudson release?

          Alan Harder added a comment -

          maxence: please respond to question above, thanks.

          Alan Harder added a comment - maxence: please respond to question above, thanks.

          maxence added a comment -

          Sorry for not replying earlier, the first notification got lost in a sea of
          emails...

          The problem I described in my last comment on Aug 7 is still accurate and
          reproducible in 1.334. Here is a simple way to reproduce the problem:

          • Make sure you have 2 executors.
          • Create a new freestyle job 'Test'.
          • Tick 'This build is parameterized' and add a 'Dummy' String parameter.
          • Add an 'Execute shell' build step with the following script: 'date && sleep
            100 && date'.
          • Save the job.
          • Schedule 5 builds with different parameter values (a/b/c/d/e), quickly enough
            so they all get queued.
          • Wait for the first build to finish.
          • Watch the 'Build history' frame: it will show two builds with a progress bar,
            just like on the attached screenshot (following).

          Hope that helps,
          Maxence

          maxence added a comment - Sorry for not replying earlier, the first notification got lost in a sea of emails... The problem I described in my last comment on Aug 7 is still accurate and reproducible in 1.334. Here is a simple way to reproduce the problem: Make sure you have 2 executors. Create a new freestyle job 'Test'. Tick 'This build is parameterized' and add a 'Dummy' String parameter. Add an 'Execute shell' build step with the following script: 'date && sleep 100 && date'. Save the job. Schedule 5 builds with different parameter values (a/b/c/d/e), quickly enough so they all get queued. Wait for the first build to finish. Watch the 'Build history' frame: it will show two builds with a progress bar, just like on the attached screenshot (following). Hope that helps, Maxence

          maxence added a comment -

          Created an attachment (id=1018)
          Corrupted 'build history' panel (2)

          maxence added a comment - Created an attachment (id=1018) Corrupted 'build history' panel (2)

          torarvid added a comment -

          Hi. Is there any progress on this issue? If not, is there any workaround?

          We have a linux master, and a windows slave (with label "win").

          Our .NET apps have matrix build jobs marked to build on label="win" ('cause they need MSBuild). We use gerrit for code review and the gerrit-trigger-plugin on our hudson server. Whenever someone pushes several commits to gerrit, it triggers several hudson builds, most of which get "ABORTED". Very frustrating...

          I am willing to do some coding/testing myself, though I have not looked at the hudson sources :-/

          torarvid added a comment - Hi. Is there any progress on this issue? If not, is there any workaround? We have a linux master, and a windows slave (with label "win"). Our .NET apps have matrix build jobs marked to build on label="win" ('cause they need MSBuild). We use gerrit for code review and the gerrit-trigger-plugin on our hudson server. Whenever someone pushes several commits to gerrit, it triggers several hudson builds, most of which get "ABORTED". Very frustrating... I am willing to do some coding/testing myself, though I have not looked at the hudson sources :-/

          torarvid added a comment -

          ... Am I asking in the wrong place? Does nobody but me have this problem?

          Just wondering

          torarvid added a comment - ... Am I asking in the wrong place? Does nobody but me have this problem? Just wondering

          maxence added a comment -

          @toravid, please take a look at issue #5653. Seems like updating to a recent version should fix your problem.

          As far as I'm concerned, parameterized builds now work properly (problem fixed).

          maxence added a comment - @toravid, please take a look at issue #5653. Seems like updating to a recent version should fix your problem. As far as I'm concerned, parameterized builds now work properly (problem fixed).

          torarvid added a comment -

          @maxence, thanks for replying. But alas, my problem still persists after upgrading to 1.386.

          So it seems there might be another cause for my problem... Maybe it has something to do with Matrix builds... (We use that to limit build slaves to those running Windows when we build .NET apps).

          torarvid added a comment - @maxence, thanks for replying. But alas, my problem still persists after upgrading to 1.386. So it seems there might be another cause for my problem... Maybe it has something to do with Matrix builds... (We use that to limit build slaves to those running Windows when we build .NET apps).

          Oleg Nenashev added a comment -

          Does anybody experience this issue?

          Oleg Nenashev added a comment - Does anybody experience this issue?

          Daniel Beck added a comment -

          No new reports in four years, it's safe to assume this is obsolete. Most of the original report (e.g. parallel builds using the same workspace) simply no longer apply anyway.

          Daniel Beck added a comment - No new reports in four years, it's safe to assume this is obsolete. Most of the original report (e.g. parallel builds using the same workspace) simply no longer apply anyway.

            Unassigned Unassigned
            huybrechts huybrechts
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: