Plugin Information |
---|
View Git Bisect on the plugin site for more information. |
This plugin helps with running git-bisect automatically in Jenkins.
Table Of Contents
Pre-Requirements
You need to:
- Be able to determine for each commit whether it's broken or not - in a single jenkins job
- If your build is separated to two projects - build & test, you can use a pipeline
and use that pipeline as a single build
- If your build is separated to two projects - build & test, you can use a pipeline
- Use Git SCM, or be able to run arbitrary git commands in the workspace
How to use this plugin
You need to have 2 Projects, let's call them "Tester Project" and "Bisect Project"
Bisect Project | Tester Project | |
---|---|---|
GitSCM |
| be able to checkout a revision using a parameter: |
Parameterized Build |
|
|
Job Type | Can be either FreeStyleProject or a Pipeline Project
Use gitbisect in Pipeline projects. | Can be either FreeStyleProject or a Pipeline Project |
Example Configuration
Bisect Project
Tester Project
Parameters
Good start revision:
Used to specify a known good commit where the thing you are testing was working properly.
Bad end revision:
Used to specify a revision where you know the thing you are testing stopped working.
Project to build:
The project that is used to test each commit. If this project fails, the revision will be marked as "bad". If this project succeeds, the revision will be marked "good".
Revision Parameter Name:
The parameter name used to pass the revision to the Tester Project. Defaults to "REVISION", other common usage might be "COMMIT" or "VERSION".
Search Identifier:
This parameter is used to distinguish between two different bisections. If the bisection stopped it can be resumed based on this identifier.
Note: This is used as a file name inside the jenkins master. You can interfere with the decisions this job makes, or add revisions to ignore by editing this file. It can be found under the project directory in jenkins, for example -
/var/jenkins/jobs/PROJECT_NAME/SEARCH_IDENTIFIER_1
Retry Number:
This parameter can be used if you have a flaky test or a flaky build system. The revision won't be defined as 'bad' until it had failed this number of times. Defaults to 0.
Min Successful runs:
This parameter can be used if you are looking for a flaky test. For example, you are looking for a commit that causes your build to fail 1 out of 5 times. So you want to increase this number accordingly. Defaults to 1.
Run as a single continues build
If this is unchecked, the test job will only run once every build. This gives you time to investigate between each run. Defaults to true.
Override Git Command
On some systems, git might not be defined in PATH or it's aliased to a different command. You can tell the job where to find it.
Running in a pipeline
Running in a pipeline currently works, but it's harder to configure.
Make sure that before the gitbisect command is used, a "checkout" or "git" command is present to set the repository.
Attachments:
image2017-9-17 22:1:59.png (image/png)
image2017-9-17 22:1:4.png (image/png)
image2017-9-17 22:0:9.png (image/png)
image2017-9-17 21:58:8.png (image/png)
image2017-9-17 21:56:41.png (image/png)
image2017-9-17 21:29:55.png (image/png)
image2017-9-17 21:24:34.png (image/png)