Branch: refs/heads/master
Home: https://github.com/jenkinsci/gerrit-trigger-plugin
Commit: d529bc132a9ed0054e9349180f2cf3a6fb51e26a
https://github.com/jenkinsci/gerrit-trigger-plugin/commit/d529bc132a9ed0054e9349180f2cf3a6fb51e26a
Author: Ferruccio Bongianni <ferruccio.bongia...@arm.com>
Date: 2022-03-16 (Wed, 16 Mar 2022)
Changed paths:
M
src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/replication/ReplicationQueueTaskDispatcher.java
M
src/test/java/com/sonyericsson/hudson/plugins/gerrit/trigger/replication/ReplicationQueueTaskDispatcherTest.java
Log Message:
-----------
JENKINS-65264: changeMerged waits for refs/heads/<branch> replica event
- When a patchset is pushed to gerrit for review, a blocked
item gets created which refers to the key
<server> + <project> + <refspec>. Such key is used to match
a replica event so that when the replica event for such key
is received, the correspondent build can be unblocked (hence
kicked off).
Such mechanism allows the build to wait for the completion
of the mirror replication.
- When the same patch gets merged (hence triggering any job
configured to trigger on change-merged event), the replica
event that will fire doesn't carry the same refspec;
instead, it will relate to the `target` branch for that
patch, for example refs/heads/master. Because of that, we
must block the build on a key that looks like:
<server> + <project> + "refs/heads/<patch branch>". By doing
so, ReplicationQueueTaskDispatcher will wait until the
successful event for such key is received, at which point
the corresponding build will be unblocked.
- Update test cases to account for the new behaviour
- One test case was failing due to having accounted for the
timestamp (useTimestampWhenProcessingRefReplicatedEvent = true)
for change merged events. The test case name is:
shouldBlockItemUntilIfPatchSetIsReplicatedToOneSlaveBeforeChangeMerged
but it was asserting that canRun() returns null, which is
what happens when the item is not blocked. This is inconsistent
with what the test case name says. Nonetheless, I believe
the correct behaviour for this test is that it should block
after the first replica event (which is fired before the
change event) but unblock on a second replica event. So I've
modified the test with this logic.
Commit: 5ca64c0c1945b86ec2ae776a484c1704c7bbed40
https://github.com/jenkinsci/gerrit-trigger-plugin/commit/5ca64c0c1945b86ec2ae776a484c1704c7bbed40
Author: Robert Sandell <rsand...@cloudbees.com>
Date: 2022-03-24 (Thu, 24 Mar 2022)
Changed paths:
M
src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/replication/ReplicationQueueTaskDispatcher.java
M
src/test/java/com/sonyericsson/hudson/plugins/gerrit/trigger/replication/ReplicationQueueTaskDispatcherTest.java
Log Message:
-----------
Merge pull request #462 from ferrucciobongianni/JENKINS-65264
[JENKINS-65264] builds triggered on changeMerged event wait for
refs/heads/<branch> replica event
Compare:
https://github.com/jenkinsci/gerrit-trigger-plugin/compare/af21088795b1...5ca64c0c1945
--
You received this message because you are subscribed to the Google Groups
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/gerrit-trigger-plugin/push/refs/heads/master/af2108-5ca64c%40github.com.
