-
New Feature
-
Resolution: Unresolved
-
Major
-
None
-
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)
Replicated on amazon-linux-ami 2017.03. Jenkins ver. 2.77Standalone 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) Replicated on amazon-linux-ami 2017.03. Jenkins ver. 2.77
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
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. |
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. |
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. |
Component/s | New: git-plugin [ 15543 ] |
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) |
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
----------------------------------------------------------------------