-
Improvement
-
Resolution: Duplicate
-
Major
The plugin is configured the following way:
- 'Compute new warnings' is activated
- 'Only use stable builds as reference' is activated
The behaviour of the plugin is incorrect when following development workflow is used:
- developer A uploads a change 'a', patch set 1 to Gerrit that fixes N warnings.
- the job for PS1 passes in Jenkins, since we have less warnings, and this build becomes the new reference
- developer A upload for change 'a' a patch set 2 to Gerrit where the initial N warnings are present again (he had removed them by 'mistake').
- the job for PS2 fails, since it refers to PS1 as a reference
In general, the same effect can be seen in various combinations: developer A and developer B upload at roughly the same time and can be blocked since e.g. developer B's job will reference non yet merged change of developer A.
An option should be added so that no passing build that has GERRIT_CHANGE_NUMBER parameter (or similar) is taken as a reference.
- duplicates
-
JENKINS-13056 Obtain reference build from SCM/Trigger
-
- Resolved
-
[JENKINS-48387] No job should be taken as a reference if it is triggered by Gerrit
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Description | Original: I would like to have a job which sends a warning mail whenever a new checkstyle warning appears in a project. However, this job should not be unstable or failing after this one new build because of the warning. With the current implementation this is not possible as the build will be failing or unstable until that warning is fixed again. A simple way to achieve this behavior is to always use the latest build as the reference build, so that old warning are bascially ignored in the new running build. |
New:
The plugin is configured the following way: * 'Compute new warnings' is activated * 'Only use stable builds as reference' is activated The behaviour of the plugin is incorrect when following development workflow is used: * developer A uploads a change 'a', patch set 1 to Gerrit that fixes N warnings. * the job for PS1 passes in Jenkins, since we have less warnings, and this build becomes the new reference * developer A upload for change 'a' a patch set 2 to Gerrit where the initial N warnings are present again (he had removed them by 'mistake'). * the job for PS2 fails, since it refers to PS1 as a reference In general, the same effect can be seen in various combinations: developer A and developer B upload at roughly the same time and can be blocked since e.g. developer B's job will reference non yet merged change of developer A. An option should be added so that no passing build that has GERRIT_CHANGE_NUMBER parameter (or similar) is taken as a reference. |
Labels | New: gerrit gerrit-trigger | |
Priority | Original: Minor [ 4 ] | New: Major [ 3 ] |
Summary | Original: CLONE - Add switch to set reference build always as the latest build | New: No job should be taken as a reference if it is triggered by Gerrit |
Resolution | Original: Fixed [ 1 ] | |
Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
Link |
New:
This issue duplicates |
Resolution | New: Duplicate [ 3 ] | |
Status | Original: Reopened [ 4 ] | New: Closed [ 6 ] |