Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70162

Aborting patch sets with same topic doesn't abort

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • gerrit-trigger-plugin
    • None
    • Jenkins 2.361.4
      Gerrit Trigger 2.37.0

      Using the "Abort patch sets with same topic" option in the 2.37.0 no longer aborts the previously triggered builds. I can see the events in the log of attempting an abort, but it doesn't work and I couldn't find any error there. Cannot replicate after reverting to plugin version 2.36.1.

      Project testTriggerTopic Build Scheduled: true By event: 24590/2
      nov 27, 2022 8:01:24 PM BUONO com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.RunningJobs cancelOutDatedEventsCancelling build for PatchsetCreated: Change-Id for #24590: I2013e3a42309593641726a6f8b552101fb2b7c98 PatchSet: 2
      nov 27, 2022 8:01:24 PM INFORMAZIONI com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.EventListener scheduleProject testTriggerTopic Build Scheduled: true By event: 24591/2
      
      
      nov 27, 2022 8:01:24 PM INFORMAZIONI com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.ToGerritRunListener onTriggeredProject [testTriggerTopic] triggered by Gerrit: [PatchsetCreated: Change-Id for #24592: I34fce4ab967500389e75821d2eb5f88a8f20b8a5 PatchSet: 2]
      nov 27, 2022 8:01:24 PM BUONO com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.RunningJobs cancelOutDatedEventsCancelling build for PatchsetCreated: Change-Id for #24591: Ie372f6fd249633573a2b36075adc341b9fb3a0a6 PatchSet: 2
      nov 27, 2022 8:01:24 PM INFORMAZIONI com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.EventListener scheduleProject testTriggerTopic Build Scheduled: true By event: 24592/2
      

       

          [JENKINS-70162] Aborting patch sets with same topic doesn't abort

          rsandell seems that this not matching anymore cancelMatchingJobs jobName. Before NULL was passed, do you have some idea?

          Michael Nazzareno added a comment - rsandell seems that this not matching anymore cancelMatchingJobs jobName. Before NULL was passed, do you have some idea?

          ckreisl added a comment -

          Hello ondrej_pik, panicking possible to provide your test scenario? Especially I'm interested in the the job settings and its Gerrit event triggers which should trigger the build.

          ckreisl added a comment - Hello ondrej_pik , panicking possible to provide your test scenario? Especially I'm interested in the the job settings and its Gerrit event triggers which should trigger the build.

          Ondrej Pik added a comment - - edited

          Hello ckreisl , I am not sure what is the best way to share it. But the job is really simple. I created a separate job just for testing this problem.

          It's pipeline project with only gerrit trigger set as shown on attached screenshots. And the Gerrit Server configuration is set like this:

          The pipeline script is just

          node() {
              sh "env"
              sh "sleep 600"
              echo "done"
          }

          The Gerrit changes (and the following new patchsets) were pushed directly to code review - not WIP/private/... .

          Let me know if I can provide some other useful information.

          Ondrej Pik added a comment - - edited Hello ckreisl , I am not sure what is the best way to share it. But the job is really simple. I created a separate job just for testing this problem. It's pipeline project with only gerrit trigger set as shown on attached screenshots. And the Gerrit Server configuration is set like this: The pipeline script is just node() {     sh "env"     sh "sleep 600"     echo "done" } The Gerrit changes (and the following new patchsets) were pushed directly to code review - not WIP/private/... . Let me know if I can provide some other useful information.

          ckreisl added a comment - - edited

          Hi ondrej_pik, finally had some time to check on this and right now I can't reproduce this problem in my test environment . I used the same Jenkins Gerrit server settings and Gerrit event job settings with the following setup.

          Jenkins vers. 2.346.3
          Gerrit 3.7

          What I did. The setup:

          1. Created a Jenkins pipeline job called "verify-a".
          2. Set the Gerrit event trigger with "Patchset created" listening on a dummy repository "repo-a".
          3. Kept the job disabled for now to prepare the Gerrit patchsets
          4. Uploaded first patch to repo-a (1)
          5. Set the topic of created patchset (1) to "topicTest"
          6. Created a second change on repo-a and uploaded it (2)
          7. Set the same topic "topicTest" to the second patchset (2)
          8. Enabled the "verify-a" job.

          Test scenario:
          1. Updated patchset (1) with a new commit which triggers "verify-a" with the correct Gerrit event parameters based on the event patchset created.
          2. Updated patchset (2) with a new commit, the triggered event successfully aborts the previously triggered "verify-a" job based on patchset (1) and triggers a new one based on the new event from patchset (2).

          //Edit. The branch for the two created patchsets was always "main" in this case.

          Anything i missed here?

          ckreisl added a comment - - edited Hi ondrej_pik , finally had some time to check on this and right now I can't reproduce this problem in my test environment . I used the same Jenkins Gerrit server settings and Gerrit event job settings with the following setup. Jenkins vers. 2.346.3 Gerrit 3.7 What I did. The setup: 1. Created a Jenkins pipeline job called "verify-a". 2. Set the Gerrit event trigger with "Patchset created" listening on a dummy repository "repo-a". 3. Kept the job disabled for now to prepare the Gerrit patchsets 4. Uploaded first patch to repo-a (1) 5. Set the topic of created patchset (1) to "topicTest" 6. Created a second change on repo-a and uploaded it (2) 7. Set the same topic "topicTest" to the second patchset (2) 8. Enabled the "verify-a" job. Test scenario: 1. Updated patchset (1) with a new commit which triggers "verify-a" with the correct Gerrit event parameters based on the event patchset created. 2. Updated patchset (2) with a new commit, the triggered event successfully aborts the previously triggered "verify-a" job based on patchset (1) and triggers a new one based on the new event from patchset (2). //Edit. The branch for the two created patchsets was always "main" in this case. Anything i missed here?

          ckreisl Try to upload a new version of the same patchset so the old one should abort but nothing is cancelled

          Michael Nazzareno added a comment - ckreisl Try to upload a new version of the same patchset so the old one should abort but nothing is cancelled

          ckreisl git bisect come here

          commit df491177aa13f60dbcdf2fb974af11c27c2295a0
          Author: ckreisl <christoph.kreisl@gmx.de>
          Date: Mon Oct 24 16:44:21 2022 +0200

          Fix leftover of "Stopped" jobs in queue

          I have a topic with 4 patches so I need to run as whole topic and build the last commit.

          Michael Nazzareno added a comment - ckreisl git bisect come here commit df491177aa13f60dbcdf2fb974af11c27c2295a0 Author: ckreisl <christoph.kreisl@gmx.de> Date: Mon Oct 24 16:44:21 2022 +0200 Fix leftover of "Stopped" jobs in queue I have a topic with 4 patches so I need to run as whole topic and build the last commit.

          Michael Nazzareno added a comment - https://github.com/jenkinsci/gerrit-trigger-plugin/pull/504

            panicking Michael Nazzareno
            ondrej_pik Ondrej Pik
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: