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

Job is run twice on first agent using label parameter

    • 1.11.0

      I have multiple agents that have multiple labels\tags. Four of those agents are online and all 4 have 'sales' (no quotes) as one of their labels.

      I add a label parameter to a job, and I specify 'sales' as the value (no quotes).

      The job runs fine, and it targets all four agents. Unfortunately, it runs twice on the first agent (5 iterations total). If I use a NODE parameter instead, and select all 4 agents, it runs 4 times (once on each).

      I have checked the box "Run on all nodes matching the label". I have selected "Run regardless of result" radio button. In terms of Node eligibility, I have selected "Ignore offline nodes".

      It has nothing to do with that particular agent (agentA), because when I take it offline, and run the job again using the same label, the job is run twice on a different agent(agentB), and only once and the other two agents (agentC,agentD).

          [JENKINS-33756] Job is run twice on first agent using label parameter

          Paul Tankard added a comment - - edited

          I hit this today, it's because of computeNextLabels() doesn't remove instances of 'label' from 'nextLabels' when looking for matches and populating it in the @DataBoundConstructor in the LabelParameterValue class

          So the runs are as follows.

          (NodeA) -> NodeA -> NodeB
          Teardown
          (NodeA) -> NodeB
          Teardown
          (NodeB)

          I'm not sure if this should be a minor bug but rather major, as if it's a long or destructive job, it would more than likely yield undesirable results.

          Paul Tankard added a comment - - edited I hit this today, it's because of computeNextLabels() doesn't remove instances of 'label' from 'nextLabels' when looking for matches and populating it in the @DataBoundConstructor in the LabelParameterValue class So the runs are as follows. (NodeA) -> NodeA -> NodeB Teardown (NodeA) -> NodeB Teardown (NodeB) I'm not sure if this should be a minor bug but rather major, as if it's a long or destructive job, it would more than likely yield undesirable results.

          Shivaji Pai added a comment -

          This issues seems to be there in 2.60.2  as well.

          Its a overload , we have a job that runs for 3 hours , the unwanted repeat is creating a overload

          Shivaji Pai added a comment - This issues seems to be there in 2.60.2  as well. Its a overload , we have a job that runs for 3 hours , the unwanted repeat is creating a overload

          I am facing the same problem.

           

          Do we have a fix for this issue ?

          Sourish Banerjee added a comment - I am facing the same problem.   Do we have a fix for this issue ?

          We have the same issue on our Jenkins instance. 

          Jenkins: 2.73.1
          Plugin: Node and Label Parameter Plugin 1.7.2
          Redhat 7

          Benjamin Dewez added a comment - We have the same issue on our Jenkins instance.  Jenkins: 2.73.1 Plugin: Node and Label Parameter Plugin 1.7.2 Redhat 7

          Humphrey Lui added a comment -

          Can you get the expected behavior after checking "Execute concurrent builds if necessary" ?

          Humphrey Lui added a comment - Can you get the expected behavior after checking "Execute concurrent builds if necessary" ?

          Jason Stanley added a comment -

          Also hitting this problem on Jenkins ver. 2.121.2 plugin version 1.7.2

          Red Hat 7

          Jason Stanley added a comment - Also hitting this problem on Jenkins ver. 2.121.2 plugin version 1.7.2 Red Hat 7

          Mark Waite added a comment - - edited

          I was trying to duplicate the issue as part of preparing to evaluate pull request 17. I'm able to duplicate the problem on one of my controllers (2.346.1-rc) but did not duplicate it on the smaller, faster controller (2.319.3).

          I assume that others still see this problem with Jenkins 2.319.3 or newer and the most recent release of the node label parameter plugin.

          Running the pull request code in my test environment, I see that the console log of the first run reports where it is building then reports the list of next nodes and lists "Schedule build on <node>" for each online node that matches the label. Then the perplexing thing happens. Sometimes, a node that is listed as being scheduled (in my case "gcp-ubuntu-22-b") is not scheduled but instead another node ("ubuntu-22-a") is scheduled a second time.

          The log statement says it is scheduling the agent, but then the actual job that is scheduled is executed on a different agent that results in two runs on the same agent.

          I believe that even with that oddity, pull request 17 is a good improvement and should be merged. I'd like some test automation inside the plugin to detect these cases, but that test automation seems likely to be quite complicated.

          Mark Waite added a comment - - edited I was trying to duplicate the issue as part of preparing to evaluate pull request 17 . I'm able to duplicate the problem on one of my controllers (2.346.1-rc) but did not duplicate it on the smaller, faster controller (2.319.3). I assume that others still see this problem with Jenkins 2.319.3 or newer and the most recent release of the node label parameter plugin. Running the pull request code in my test environment, I see that the console log of the first run reports where it is building then reports the list of next nodes and lists "Schedule build on <node>" for each online node that matches the label. Then the perplexing thing happens. Sometimes, a node that is listed as being scheduled (in my case "gcp-ubuntu-22-b") is not scheduled but instead another node ("ubuntu-22-a") is scheduled a second time. The log statement says it is scheduling the agent, but then the actual job that is scheduled is executed on a different agent that results in two runs on the same agent. I believe that even with that oddity, pull request 17 is a good improvement and should be merged. I'd like some test automation inside the plugin to detect these cases, but that test automation seems likely to be quite complicated.

            domi Dominik Bartholdi
            pimyjenkins Rob Pimentel
            Votes:
            4 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: