CopyAllScores fails to copy if new changeset is upload before build was finished
47 views
Skip to first unread message
Peter Bruin
Jan 9, 2018, 8:29:49 PM1/9/18
to Repo and Gerrit Discussion
I am using the below config for my project. This works as expected when the change was verified and a new patchset was uploaded with just a comment change.
The problem is now that when a user amends the change by changing the comment, for example a forgotten bug tracking number, and the build completes after this.
Jenkins will at this point verify the old patchset and the new patchset does not receive the score.
Jenkins will also not trigger a new build as there was no code change and the change can not be submitted as it is not verified.
At this point the project owner needs to step in and manually verify the change.
Is there any way that I can fix this?
[label "Verified"]
function = MaxWithBlock
value = -1 Fails
value = 0 No score
value = +1 Verified
copyAllScoresIfNoCodeChange = true
copyAllScoresOnTrivialRebase = true
defaultValue = 0
Matthew Webber
Jan 10, 2018, 9:43:47 AM1/10/18
to Repo and Gerrit Discussion
On Wednesday, 10 January 2018 01:29:49 UTC, Peter Bruin wrote:
I am using the below config for my project. This works as expected when the change was verified and a new patchset was uploaded with just a comment change.The problem is now that when a user amends the change by changing the comment, for example a forgotten bug tracking number, and the build completes after this.Jenkins will at this point verify the old patchset and the new patchset does not receive the score.Jenkins will also not trigger a new build as there was no code change and the change can not be submitted as it is not verified.At this point the project owner needs to step in and manually verify the change.Is there any way that I can fix this?
<< snip >>
We have exactly the same problem.I don't have any solution (other than manual intervention as described by you, or else re-triggering the build). Fortunately it happens fairly infrequently, so we put up with the manual handling required.
Since Gerrit knows when a patch set N+1 is identical (code-wise) to patch set N, it should be possible for a Verified+1 for patch set N to be copied forward to an existing patch set N+1. However, the code does not do that at the moment.
Dave Borowitz
Jan 10, 2018, 9:54:39 AM1/10/18
to Matthew Webber, Repo and Gerrit Discussion
This should work as you expect if you're using the NoteDb backend for changes. Consider that a carrot for migrating in 2.15 :) (I'll let code historians argue about whether introducing this behavior change between ReviewDb and NoteDb was a good idea in retrospect.)
--
--
To unsubscribe, email repo-discuss+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Matthew Webber
Jan 10, 2018, 10:18:41 AM1/10/18
to Repo and Gerrit Discussion
On Wednesday, 10 January 2018 14:54:39 UTC, Dave Borowitz wrote:
This should work as you expect if you're using the NoteDb backend for changes. Consider that a carrot for migrating in 2.15 :)
That's excellent; I wasn't aware of that change.
Believe me, we'll be moving to 2.15 just as soon as it is released!
Peter Bruin
Jan 10, 2018, 8:30:48 PM1/10/18
to Repo and Gerrit Discussion
Great, will wait for the 2.15 release, thanks
On Wednesday, 10 January 2018 22:54:39 UTC+8, Dave Borowitz wrote:
On Wed, Jan 10, 2018 at 9:43 AM, Matthew Webber <mat...@unsolvable.org> wrote:On Wednesday, 10 January 2018 01:29:49 UTC, Peter Bruin wrote:I am using the below config for my project. This works as expected when the change was verified and a new patchset was uploaded with just a comment change.The problem is now that when a user amends the change by changing the comment, for example a forgotten bug tracking number, and the build completes after this.Jenkins will at this point verify the old patchset and the new patchset does not receive the score.Jenkins will also not trigger a new build as there was no code change and the change can not be submitted as it is not verified.At this point the project owner needs to step in and manually verify the change.Is there any way that I can fix this?<< snip >>We have exactly the same problem.I don't have any solution (other than manual intervention as described by you, or else re-triggering the build). Fortunately it happens fairly infrequently, so we put up with the manual handling required.Since Gerrit knows when a patch set N+1 is identical (code-wise) to patch set N, it should be possible for a Verified+1 for patch set N to be copied forward to an existing patch set N+1. However, the code does not do that at the moment.This should work as you expect if you're using the NoteDb backend for changes. Consider that a carrot for migrating in 2.15 :) (I'll let code historians argue about whether introducing this behavior change between ReviewDb and NoteDb was a good idea in retrospect.)
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.
Reply all
Reply to author
Forward
0 new messages