-
Improvement
-
Resolution: Fixed
-
Major
-
None
-
Jenkins: 2.452.1
OS: Linux - 4.18.0-553.5.1.el8_10.x86_64
Java: 17.0.11 - Red Hat, Inc. (OpenJDK 64-Bit Server VM)
---
forensics-api:2.4.0
warnings-ng:11.3.0
{{discoverReferenceBuild }}will not update to the latest completed build after being called for the first time.
Scenario:
- Build A is completed
- Build B starts
- Build C starts and calls discoverReferenceJob -> points to A
- Build B publishes some report with the same ID as used in the other jobs
- Build C calls discoverReferenceJob again -> Reference Build switches to B but WarningsNG still uses A.
Behavior before the switch to Forensics API was that Job C's delta would have pointed to Job B as soon as it published the report. Now, even after calling discoverReferenceJob, it doesn't update.
The reference build is correctly set to the latest completed one, but warningsNG sticks with the one found when discoverReferenceBuild was called the first time.
-> Updating WarningsNG breaks some pipeline logic from us.
[JENKINS-73380] discoverReferenceJob doesn't update if other job completes in the meantime
Jan
created issue -
Jan
made changes -
| Description |
Original:
{{discoverReferenceJob }}will not update to the latest completed job after being called for the first time.
Scenario: Job A is completed Job B starts. Job C starts and calls discoverReferenceJob -> points to A. Job B publishes some report with the same ID as used in the other jobs. Job C calls discoverReferenceJob again -{*}> Reference Build switches to B but WarningsNG still uses A.{*} Behaviour before the switch to Forensics API was that the reference would update to the latest available report / build. The reference build is correctly set to the latest completed one, but warningsNG sticks with the one found when discoverReferenceBuild was called the first time. -> Updating WarningsNG breaks some pipeline logic from us. |
New:
{\{discoverReferenceJob }}will not update to the latest completed job after being called for the first time.
Scenario: Job A is completed Job B starts. Job C starts and calls discoverReferenceJob -> points to A. Job B publishes some report with the same ID as used in the other jobs. Job C calls discoverReferenceJob again -{*}> Reference Build switches to B but WarningsNG still uses A.{*} Behaviour before the switch to Forensics API was that Job C's delta would have pointed to Job B as soon as it published the report. The reference build is correctly set to the latest completed one, but warningsNG sticks with the one found when discoverReferenceBuild was called the first time. -> Updating WarningsNG breaks some pipeline logic from us. |
Jan
made changes -
| Description |
Original:
{\{discoverReferenceJob }}will not update to the latest completed job after being called for the first time.
Scenario: Job A is completed Job B starts. Job C starts and calls discoverReferenceJob -> points to A. Job B publishes some report with the same ID as used in the other jobs. Job C calls discoverReferenceJob again -{*}> Reference Build switches to B but WarningsNG still uses A.{*} Behaviour before the switch to Forensics API was that Job C's delta would have pointed to Job B as soon as it published the report. The reference build is correctly set to the latest completed one, but warningsNG sticks with the one found when discoverReferenceBuild was called the first time. -> Updating WarningsNG breaks some pipeline logic from us. |
New:
{\{discoverReferenceJob }}will not update to the latest completed job after being called for the first time.
Scenario: Job A is completed Job B starts. Job C starts and calls discoverReferenceJob -> points to A. Job B publishes some report with the same ID as used in the other jobs. Job C calls discoverReferenceJob again -{*}> Reference Build switches to B but WarningsNG still uses A.{*} Behaviour before the switch to Forensics API was that Job C's delta would have pointed to Job B as soon as it published the report. Now, even after calling discoverReferenceJob, it doesn't update. The reference build is correctly set to the latest completed one, but warningsNG sticks with the one found when discoverReferenceBuild was called the first time. -> Updating WarningsNG breaks some pipeline logic from us. |
Jan
made changes -
| Attachment | New: antwort_uli.txt [ 62920 ] |
Jan
made changes -
| Attachment | Original: antwort_uli.txt [ 62920 ] |
Jan
made changes -
| Attachment | New: warnings_ng.txt [ 62921 ] |
Jan
made changes -
| Attachment | New: image-2024-07-03-12-10-23-597.png [ 62922 ] |
Thanks for your response!
Yes, sorry - build.
discoverReferenceBuild is indeed being called multiple times per build - I would have expected that calling it again would allow updating the reference (just as it behaved before without Forensics API, where the reference updated automatically)
I attached the warningsNG output, including at the very end the reference output. Interestingly, the log shows that it takes 1643 (just once) and the UI shows that it updated:
(rev1.1643 = # 1257, rev1.1644 = # 1258, screenshots from rev1.1645 = # 1259)
This is a significant problem, as in the other issue (JENKINS-73328): if the in-progress report finds that issues were fixed, the already running next build would not detect this and show a wrong delta and thus wrong blame. This is a big no-go for audit-sensitive projects. One run may show that its changes fixed something even though the previous run was responsible.
Jan
added a comment - - edited Thanks for your response!
Yes, sorry - build.
discoverReferenceBuild is indeed being called multiple times per build - I would have expected that calling it again would allow updating the reference (just as it behaved before without Forensics API, where the reference updated automatically)
I attached the warningsNG output, including at the very end the reference output. Interestingly, the log shows that it takes 1643 (just once) and the UI shows that it updated:
(rev1.1643 = # 1257, rev1.1644 = # 1258, screenshots from rev1.1645 = # 1259)
This is a significant problem, as in the other issue ( JENKINS-73328 ): if the in-progress report finds that issues were fixed, the already running next build would not detect this and show a wrong delta and thus wrong blame. This is a big no-go for audit-sensitive projects. One run may show that its changes fixed something even though the previous run was responsible.
| Description |
Original:
{\{discoverReferenceJob }}will not update to the latest completed job after being called for the first time.
Scenario: Job A is completed Job B starts. Job C starts and calls discoverReferenceJob -> points to A. Job B publishes some report with the same ID as used in the other jobs. Job C calls discoverReferenceJob again -{*}> Reference Build switches to B but WarningsNG still uses A.{*} Behaviour before the switch to Forensics API was that Job C's delta would have pointed to Job B as soon as it published the report. Now, even after calling discoverReferenceJob, it doesn't update. The reference build is correctly set to the latest completed one, but warningsNG sticks with the one found when discoverReferenceBuild was called the first time. -> Updating WarningsNG breaks some pipeline logic from us. |
New:
{\{discoverReferenceBuild }}will not update to the latest completed build after being called for the first time.
Scenario: # Build A is completed # Build B starts # Build C starts and calls discoverReferenceJob -> points to A # Build B publishes some report with the same ID as used in the other jobs # Build C calls discoverReferenceJob again -{*}> Reference Build switches to B but WarningsNG still uses A.{*} Behavior before the switch to Forensics API was that Job C's delta would have pointed to Job B as soon as it published the report. Now, even after calling discoverReferenceJob, it doesn't update. The reference build is correctly set to the latest completed one, but warningsNG sticks with the one found when discoverReferenceBuild was called the first time. -> Updating WarningsNG breaks some pipeline logic from us. |
I am assuming you mean build and not job in your example?
Are you using discoverReferenceBuild multiple times in one build? The action is supposed to be called only once per build.
Can you please add the logging output of the warnings plugin?