Verified 0 (vote reset) does not actually reset vote

[Erik Thorsell]

We have a Gerrit + Jenkins setup running since many years back. In July I went through the process of updating Gerrit from 3.5.0.1 to 3.10 and everything has been working great, apart from one thing.

In our Jenkins instance, we make use of the Gerrit Trigger Plugin and the Jenkins <-> Gerrit dance seems to work fine in most regards. However, when a change is updated the Verified 0 (vote reset) command does not correctly remove the Verified label.

The image below shows the problem. Note how jenkins has sent the Verified 0 (vote reset) command back to Gerrit, but the Verified label (at the top of the screen) is still present.

In practice, this means that a developer can amend a change [which will trigger a new Jenkins build and a vote reset] and ask a colleague to review the modification. If the colleague is pleased with the change they can Reply with +2 and the developer can then go ahead and submit their change [while the new Jenkins build is running].

To me, it seems like the Gerrit Trigger plugin is correctly sending back the vote reset command, but Gerrit does not treat it the way it ought to. Anyone else seen the same issue and/or have a solution?

[Björn Pedersen]

Erik Thorsell schrieb am Freitag, 13. September 2024 um 13:09:37 UTC+2:

We have a Gerrit + Jenkins setup running since many years back. In July I went through the process of updating Gerrit from 3.5.0.1 to 3.10 and everything has been working great, apart from one thing.

In our Jenkins instance, we make use of the Gerrit Trigger Plugin and the Jenkins <-> Gerrit dance seems to work fine in most regards. However, when a change is updated the Verified 0 (vote reset) command does not correctly remove the Verified label.

The image below shows the problem. Note how jenkins has sent the Verified 0 (vote reset) command back to Gerrit, but the Verified label (at the top of the screen) is still present.

 

To me, it seems like the Gerrit Trigger plugin is correctly sending back the vote reset command, but Gerrit does not treat it the way it ought to. Anyone else seen the same issue and/or have a solution?

did you do a force-relaod of the page before checking? Since 3.9 the gerrit frontend is  sometimes caching to aggressive so that e.g. label updates are not propagated immediatly ( the backend still  works correctly, so a submit woudl be rejected).

[Erik Thorsell]

Thanks for your input Björn.

It took a while to get to testing your theory, but I sat down with a developer and I think we concluded that this is not just a graphical issue.

In the image below it is possible to submit a topic (and the Verified label is set) even though the Jenkins build has just started (and is currently running).

Am I missing something obvious here? Since this is the first patch set, "forcing a reload to clear any previous verified-label" ought not to matter. Right?

Best regards,

Erik

[Erik Thorsell]

I have once again concluded that the error seems to be persistent. A developer just linked me a change where he was able to submit while Jenkins was running its build.

However, I went back to double check the Submit Requirements and the Labels we have configured and when cross-referencing with the documentation I found this example for how to configure Label: Verified:

[label "Verified"]
      function = MaxWithBlock
      value = -1 Fails
      value = 0 No score
      value = +1 Verified
      copyCondition = changekind:NO_CODE_CHANGE

But ours was defined as:

[label "Verified"]
function = NoBlock
defaultValue = 0
value = -1 Fails
value = 0 No score
value = +1 Verified
copyCondition = changekind:NO_CODE_CHANGE

Reading further, it seems like the function parameter is deprecated (https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_function) and the example in the documentation is incorrect. I went further and looked at the Submit Requirements and found this:

[submit-requirement "Verified"]
description = Disallow changes to be merged which have label Verified: -1
submittableIf = -label:Verified=MIN
canOverrideInChildProjects = true

Which seems to allow submitting changes where the label is set to 0. I updated this to:

[submit-requirement "Verified"]
description = Only allow changes to be submitted if they have Verified +1
submittableIf = label:Verified=MAX and -label:Verified=MIN
canOverrideInChildProjects = true

And I will test whether this works better.

[Matthias Sohn]

On Thu, Oct 10, 2024 at 10:10 AM Erik Thorsell <thorse...@gmail.com> wrote:

I have once again concluded that the error seems to be persistent. A developer just linked me a change where he was able to submit while Jenkins was running its build.

However, I went back to double check the Submit Requirements and the Labels we have configured and when cross-referencing with the documentation I found this example for how to configure Label: Verified:

[label "Verified"]
      function = MaxWithBlock
      value = -1 Fails
      value = 0 No score
      value = +1 Verified
      copyCondition = changekind:NO_CODE_CHANGE

But ours was defined as:

[label "Verified"]
function = NoBlock
defaultValue = 0
value = -1 Fails
value = 0 No score
value = +1 Verified
copyCondition = changekind:NO_CODE_CHANGE

Reading further, it seems like the function parameter is deprecated (https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_function) and the example in the documentation is incorrect.

I pushed a change improving the documentation to explain how to configure a submit requirement instead of using `function = MaxWithBlock`

https://gerrit-review.googlesource.com/c/gerrit/+/439141

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/72da4d5b-a74b-4689-91af-cdfaaec5bdaen%40googlegroups.com.