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

Git polling doesn't execute concurrent builds if necessary

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • git-plugin
    • None
    • windows xp

      We would like to make use off git polling more than it does now.
      We've selected to poll every five minutes for changes because we commit a lot.
      Our projects take approximately 50 to 70 minutes to build and we've got over a dozen machines that can build for us.

      What we would like is that every five minutes a build would start if there are changes, but this doesn't happen. We've selected Execute concurrent builds if necessary (beta) but git doesn't start the actual polling again after the build is done.

          [JENKINS-7423] Git polling doesn't execute concurrent builds if necessary

          This will be shown untill started job is completed

          anonymousultimo added a comment - This will be shown untill started job is completed

          Mark Waite added a comment -

          It may not be a very helpful work around for you, but I found with my experiments that I was able to start a concurrent build and the git plugin detected its changes, so long as I launched the concurrent build myself, rather than relying on SCM polling to detect the change.

          Since there are command line calls and wget calls which can launch a concurrent build, maybe you could detect the changes to the git repository from another program (a shell script, a python program, etc.), then when a git change was detected, launch the build yourself.

          For example, I have a job whose job name is "parallel". I can start multiple copies of that job by running the command:

          wget http://127.0.0.1:8080/job/parallel/build?delay=0sec

          If you were to probe your source master "every so often", then run that command when an actual source change was detected by your probing program, I think you would get the result you want.

          That is just a work around, not a real fix, but it would let you experiment further with the idea of concurrent builds, without waiting for a fix from the Jenkins developers.

          Mark Waite added a comment - It may not be a very helpful work around for you, but I found with my experiments that I was able to start a concurrent build and the git plugin detected its changes, so long as I launched the concurrent build myself, rather than relying on SCM polling to detect the change. Since there are command line calls and wget calls which can launch a concurrent build, maybe you could detect the changes to the git repository from another program (a shell script, a python program, etc.), then when a git change was detected, launch the build yourself. For example, I have a job whose job name is "parallel". I can start multiple copies of that job by running the command: wget http://127.0.0.1:8080/job/parallel/build?delay=0sec If you were to probe your source master "every so often", then run that command when an actual source change was detected by your probing program, I think you would get the result you want. That is just a work around, not a real fix, but it would let you experiment further with the idea of concurrent builds, without waiting for a fix from the Jenkins developers.

          Danny Staple added a comment -

          Update the title to be more descriptive. Has this been verified as being in the git plugin and not a general SCM issue?

          Danny Staple added a comment - Update the title to be more descriptive. Has this been verified as being in the git plugin and not a general SCM issue?

          Andrew Bayer added a comment -

          This is valid - the git plugin requires access to the workspace for polling, and so can't poll for changes while a build is running. Workarounds include changing to using post-receive hooks, having a parent job that does nothing but poll and if it finds changes, kick off the real build, etc.

          Andrew Bayer added a comment - This is valid - the git plugin requires access to the workspace for polling, and so can't poll for changes while a build is running. Workarounds include changing to using post-receive hooks, having a parent job that does nothing but poll and if it finds changes, kick off the real build, etc.

          general jenkins issue
          possible workarounds :

          • use a commit hook to trigger a build
          • use single branch setting so no workspace is required for polling

          Nicolas De Loof added a comment - general jenkins issue possible workarounds : use a commit hook to trigger a build use single branch setting so no workspace is required for polling

          Jan Klass added a comment -

          Why was this closed as won’t fix?

          Jan Klass added a comment - Why was this closed as won’t fix?

            ndeloof Nicolas De Loof
            anonymousultimo anonymousultimo
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: