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

          Eric Griswold created issue -
          Eric Griswold made changes -
          Description Original: 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
          * Commit and run a build. It should fail. Note Git SHA (This is build #1)
          * Make a second build and run it. It should also fail. Note the Git SHA (This is build #2)
          * Now go back to build #1 and retrigger it.

          My expectation is that the retriggered build should have the same Git SHA as build #1. When I try it, the Git SHA is the HEAD of the branch at the time of the retrigger.
          New: 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
          * Commit and run a build. It should fail. Note Git SHA (This is build #1)
          * Make a second build and run 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 have the same Git SHA as build #1.

          Observed problem:

          The Git SHA is the HEAD of the branch at the time of the retrigger.
          Eric Griswold made changes -
          Description Original: 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
          * Commit and run a build. It should fail. Note Git SHA (This is build #1)
          * Make a second build and run 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 have the same Git SHA as build #1.

          Observed problem:

          The Git SHA is the HEAD of the branch at the time of the retrigger.
          New: 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 have the same Git SHA as build #1.

          Observed problem:

          The Git SHA is the HEAD of the branch at the time of the retrigger.
          Eric Griswold made changes -
          Description Original: 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 have the same Git SHA as build #1.

          Observed problem:

          The Git SHA is the HEAD of the branch at the time of the retrigger.
          New: 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.

          Federico Naum added a comment -

          I'm experiencing the same issue:

          Environmnet: CentOS-6.6
          Jenkins 1.628
          git-client 1.19.0
          github-api plugin 1.69
          github-plugin 1.13.3
          rebuilder 1.25

          The rebuilder plugin does not take into account the revision that was built.

          Looking at the Status of the build, this is what I see: (Note: Git Build Data shows the same information on the commits)

          ----------------------------------------------------------
          Build #1
          Changes
          test1 (commit: bb78bfa2a67d1feb0a6ff887ec4f09aafbba5fa6) (detail)

          Started by an SCM change

          Revision: bb78bfa2a67d1feb0a6ff887ec4f09aafbba5fa6
          origin/master
          ----------------------------------------------------------------------

          make another change

          ----------------------------------------------------------------------
          Build #2
          Changes
          test2 (commit: ec56d24cb0fab5fc41963b22d1ae9af0871a14b9) (detail)

          Started by an SCM change

          Revision: ec56d24cb0fab5fc41963b22d1ae9af0871a14b9
          origin/master
          ----------------------------------------------------------------------

          Now when I go to build #1 and press rebuild, It ends up rebuilding against the last sha (ec56d24cb0fab5fc41963b22d1ae9af0871a14b9 from #2) instead of #1

          ----------------------------------------------------------------------
          Build #3

          No changes.

          Started by an SCM change

          Started by GitHub push by USERNAME

          Started by user USER NAME

          Rebuilds build #1

          Revision: ec56d24cb0fab5fc41963b22d1ae9af0871a14b9
          origin/master
          ----------------------------------------------------------------------

          Federico Naum added a comment - I'm experiencing the same issue: Environmnet: CentOS-6.6 Jenkins 1.628 git-client 1.19.0 github-api plugin 1.69 github-plugin 1.13.3 rebuilder 1.25 The rebuilder plugin does not take into account the revision that was built. Looking at the Status of the build, this is what I see: (Note: Git Build Data shows the same information on the commits) ---------------------------------------------------------- Build #1 Changes test1 (commit: bb78bfa2a67d1feb0a6ff887ec4f09aafbba5fa6) (detail) Started by an SCM change Revision: bb78bfa2a67d1feb0a6ff887ec4f09aafbba5fa6 origin/master ---------------------------------------------------------------------- make another change ---------------------------------------------------------------------- Build #2 Changes test2 (commit: ec56d24cb0fab5fc41963b22d1ae9af0871a14b9) (detail) Started by an SCM change Revision: ec56d24cb0fab5fc41963b22d1ae9af0871a14b9 origin/master ---------------------------------------------------------------------- Now when I go to build #1 and press rebuild, It ends up rebuilding against the last sha (ec56d24cb0fab5fc41963b22d1ae9af0871a14b9 from #2) instead of #1 ---------------------------------------------------------------------- Build #3 No changes. Started by an SCM change Started by GitHub push by USERNAME Started by user USER NAME Rebuilds build #1 Revision: ec56d24cb0fab5fc41963b22d1ae9af0871a14b9 origin/master ----------------------------------------------------------------------

          Mattias Vannergård added a comment - - edited

          I have the same problem with the Retrigger function in the Gerrit Trigger plugin, so I think it is a fault in the Git plugin, because all the Parameters and Environment Variables are correct, but the Git Build Data is wrong.

          Mattias Vannergård added a comment - - edited I have the same problem with the Retrigger function in the Gerrit Trigger plugin, so I think it is a fault in the Git plugin, because all the Parameters and Environment Variables are correct, but the Git Build Data is wrong.
          Mattias Vannergård made changes -
          Component/s New: git-plugin [ 15543 ]
          Mattias Vannergård made changes -
          Environment Original: Standalone CentOS 7 machine. Jenkins 1.622; Git plugin 2.4.0; Naginator 1.15; rebuilder 1.25

          Replicated on a CentOS 6 machine. Jenkins 1.580.3; Git plugin 2.3.5; Naginator 1.14; Rebuilder 1.22
          New: Standalone CentOS 7 machine. Jenkins 1.622; Git plugin 2.4.0; Naginator 1.15; rebuilder 1.25

          Replicated on a CentOS 6 machine. Jenkins 1.580.3; Git plugin 2.3.5; Naginator 1.14; Rebuilder 1.22

          Replicated on a Win 7 machine. Jenkins 1.596.2; Git plugin 2.4.0; Gerrit plugin 2.16.0; Rebuilder 1.25 (I do have Naginator 1.15 installed, but it is not involved in this job)

          Daniel Beck added a comment -

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

          Not a maintainer of any of these plugins, but I think this is how they're supposed to work. In the case of Rebuild, it just saves you from having to enter the same parameters again when you want the "same" build, but it doesn't care about SCM.

          Daniel Beck added a comment - The Git SHA is the HEAD of the branch at the time of the retrigger. Not a maintainer of any of these plugins, but I think this is how they're supposed to work. In the case of Rebuild, it just saves you from having to enter the same parameters again when you want the "same" build, but it doesn't care about SCM.

          Mark Waite added a comment -

          I think danielbeck is correct about the expected behavior of Naginator and Rebuild plugins. They make no mention of retrying a specific SCM revision, only about retrying a build (or a parameterized build). I don't see a "Gerrit Retrigger" plugin in the list of Jenkins plugins, so I can't read its documentation to see if it mentions any expectation of rebuilding the same SCM revision as the previous build.

          Mark Waite added a comment - I think danielbeck is correct about the expected behavior of Naginator and Rebuild plugins. They make no mention of retrying a specific SCM revision, only about retrying a build (or a parameterized build). I don't see a "Gerrit Retrigger" plugin in the list of Jenkins plugins, so I can't read its documentation to see if it mentions any expectation of rebuilding the same SCM revision as the previous build.

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

              Created:
              Updated: