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

Build Retry (both Naginator and Rebuild) pick the latest commit, not retrying one

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • None

      This is easily reproduced on a standalone Cent 6 or Cent 7 machine.

      Create a job:

      • Uses Git
      • A trivial build step that fails, "false" or "exit 1" in the shell build-step for example
      • Uses one of the above retry mechanisms (Naginator or Rebuilder)
      • In the case of Naginator, stub it with a regex to keep it from automatically retrying
      • In the case of Rebuilder, enable the rebuild without parameters
      • Make a commit and run a build. It should fail. Note Git SHA (This is build #1)
      • Make a second commit, then build it. It should also fail. Note the Git SHA (This is build #2)
      • Now go back to build #1 and retrigger it. (build #3)

      Expectation:

      The retriggered build (build #3) should use the same Git SHA as build #1.

      Observed problem:

      The Git SHA is the HEAD of the branch at the time of the retrigger.

          [JENKINS-29765] Build Retry (both Naginator and Rebuild) pick the latest commit, not retrying one

          OK. It was just a guess from my side. Now I have learned more, and that the Gerrit Trigger actually can do it. I had done the configurarion of the Gerrit Trigger wrong, so it was not actually retriggerable. Removing my tag.

          Mattias Vannergård added a comment - OK. It was just a guess from my side. Now I have learned more, and that the Gerrit Trigger actually can do it. I had done the configurarion of the Gerrit Trigger wrong, so it was not actually retriggerable. Removing my tag.

          Federico Naum added a comment -

          Thanks all, I understand now that the main functionality of the rebuild-plugin is to save you from having to enter the same explicit parameters again. But I still think that the desired behaviour should be to gather somehow the SCM revision from the SCM plugins and rebuild that instead of HEAD/the last revision built. It feels to me that the SCM revision is sort of an implicit parameter of a given build? Could it be done as an option in the rebuild page asking you whether or not to include the SCM data?

          Without knowing the architecture/code, I imagine something like markewaite mentioned. When rebuild is pressed on build X, then the rebuild-plugin asks Jenkins core or the SCM plugins which was the revision used to build X.

          I'm happy for this to be considered a nice to have instead of a Major issue, so please feel free to lower the priority to whatever you think is best for this type of issue

          Federico Naum added a comment - Thanks all, I understand now that the main functionality of the rebuild-plugin is to save you from having to enter the same explicit parameters again. But I still think that the desired behaviour should be to gather somehow the SCM revision from the SCM plugins and rebuild that instead of HEAD/the last revision built. It feels to me that the SCM revision is sort of an implicit parameter of a given build? Could it be done as an option in the rebuild page asking you whether or not to include the SCM data? Without knowing the architecture/code, I imagine something like markewaite mentioned. When rebuild is pressed on build X, then the rebuild-plugin asks Jenkins core or the SCM plugins which was the revision used to build X. I'm happy for this to be considered a nice to have instead of a Major issue, so please feel free to lower the priority to whatever you think is best for this type of issue

          ikedam added a comment -

          Rebuild and naginator just replay "retrieve HEAD" of git-plugin as pointed by danielbeck.
          Rebuilding plugins doesn't know about git-plugin and can do nothing for this by themselves.

          Possible solutions:

          • Git-plugin provides an implementation for rebuilding plugins to set up the new build to retrieve the last commit. This is just like GitRevisionBuildParameters provided by git-plugin for parameterized-trigger plugin.
            • This requires rebuilding plugins provide an extension point for this. Git-plugin have to provide implementations for each plugins as they provide their own extension points.
          • Git-plugin detects the rebuilded origin build and extract the used commit.
            • Rebuilding plugins provides information to track the origin build in their own ways.

          ikedam added a comment - Rebuild and naginator just replay "retrieve HEAD" of git-plugin as pointed by danielbeck . Rebuilding plugins doesn't know about git-plugin and can do nothing for this by themselves. Possible solutions: Git-plugin provides an implementation for rebuilding plugins to set up the new build to retrieve the last commit. This is just like GitRevisionBuildParameters provided by git-plugin for parameterized-trigger plugin. This requires rebuilding plugins provide an extension point for this. Git-plugin have to provide implementations for each plugins as they provide their own extension points. Git-plugin detects the rebuilded origin build and extract the used commit. Rebuilding plugins provides information to track the origin build in their own ways.

          Would love to see this feature. Or is there an alternative?

          Pascal Brouwers added a comment - Would love to see this feature. Or is there an alternative?

          Mark Waite added a comment -

          The Jenkins pipeline includes a capability called "Replay" which will run the same build again. I believe it uses the same SHA1 (or subversion commit) on a replay build as it did on the original build.

          Mark Waite added a comment - The Jenkins pipeline includes a capability called "Replay" which will run the same build again. I believe it uses the same SHA1 (or subversion commit) on a replay build as it did on the original build.

          Hi,

          I'm facing the same problem in a jenkins project building lots of git branches where we have quite often activity (pushes).. really often there are failed jobs that I want to retry but effectively it's always the last build that was run which is retried, and not the one on which I actually retry ..

          any high level idea when this feature/bugfix could be foreseen/released :-?

          Many thx.

          Grégory Starck added a comment - Hi, I'm facing the same problem in a jenkins project building lots of git branches where we have quite often activity (pushes).. really often there are failed jobs that I want to retry but effectively it's always the last build that was run which is retried, and not the one on which I actually retry .. any high level idea when this feature/bugfix could be foreseen/released :-? Many thx.

          Mark Waite added a comment -

          I have no plans to implement any changes to support this in the git plugin or the git client plugin. I believe the necessary API calls are already available, as evidenced by the pipeline "Replay" function. The pipeline "Replay" uses the same commit in the new build as was used in the original build.

          Mark Waite added a comment - I have no plans to implement any changes to support this in the git plugin or the git client plugin. I believe the necessary API calls are already available, as evidenced by the pipeline "Replay" function. The pipeline "Replay" uses the same commit in the new build as was used in the original build.

          Daniel Beck added a comment -

          as evidenced by the pipeline "Replay" function

          It stores the revision in the job config, which results in side effects such as polling being stupidly broken: JENKINS-40722

          Daniel Beck added a comment - as evidenced by the pipeline "Replay" function It stores the revision in the job config, which results in side effects such as polling being stupidly broken: JENKINS-40722

          ming fan added a comment -

          Have the same issue withJenkins ver. 2.77

          ming fan added a comment - Have the same issue withJenkins ver. 2.77

          Sean LeBlanc added a comment -

          Would it be true that the only way to work around this would be to change the job to a Jenkins pipeline and use Replay instead? Right now we have jobs that build new changes on any branch, but re-running any of them is basically impossible unless it's the latest change only.

           

          By the way, we also noticed that limiting the jobs by Ancestry (going back no more than N days, for instance) would block rebuild from working at all.

          Sean LeBlanc added a comment - Would it be true that the only way to work around this would be to change the job to a Jenkins pipeline and use Replay instead? Right now we have jobs that build new changes on any branch, but re-running any of them is basically impossible unless it's the latest change only.   By the way, we also noticed that limiting the jobs by Ancestry (going back no more than N days, for instance) would block rebuild from working at all.

            Unassigned Unassigned
            eegah Eric Griswold
            Votes:
            14 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated: