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

job-restrictions Job Property does not support Pipeline Plugin

      job-restrictions-plugin does not support Pipeline Plugin (aka Workflow plugin) and it's behavior is not as expected.

      Steps to reproduce it:

      Create a job using Pipeline Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin)
      Create a slave in your master called for example 'demo-slave'.

      In your Groovy script using pipeline do:

      node('master') {

      }

      node('demo-slave') {

      }

      After in 'demo-slave' configuration, restrict it:

      No matter if you start your job with 'daniel_hernandez' user or other user, the job will not get a executor from the demo-slave node getting the message:

      Waiting for next available executor on demo-slave

      After, You can release it setting the value to 'Take any job'

        1. Captura.PNG
          Captura.PNG
          18 kB
        2. job-restrictions.hpi
          62 kB
        3. screenshot-1.png
          screenshot-1.png
          5 kB

          [JENKINS-34377] job-restrictions Job Property does not support Pipeline Plugin

          Hi !, sorry I couldn't replied quick. Regarding this "cancel jobs not meeting this restriction" sounds great, I just wonder oleg_nenashev mansoor why this behavior cant be as default? What would be the reason to hang the process? If the user can't run jobs in that Node and then it hangs , how this job will be released?

          I hope to test it again by this weekend.

          Thanks !

          Daniel Alejandro Hernández added a comment - Hi !, sorry I couldn't replied quick. Regarding this "cancel jobs not meeting this restriction" sounds great, I just wonder oleg_nenashev mansoor why this behavior cant be as default? What would be the reason to hang the process? If the user can't run jobs in that Node and then it hangs , how this job will be released? I hope to test it again by this weekend. Thanks !

          Hi oleg_nenashev mansoor I have give it a try and it still working fine the expected scenario.

          Just a few comments with a common scenario:

          When you run a job with a user that has no grant over the Node to run jobs there so the job will be queued or stuck with the label "pending - waiting for next available executor".

          Then if a different user try to run the same job but has the correct grants further job will not run until manually stop or cancel previous job and then trigger the new ones. I did check that the job can run concurrent builds and the Node has enough executors and regardless that the new builds cannot run until manually release the one that is "pending - waiting for next available executor" status.

          So with this miss behaviors can arise, for instance if there a job with the status "pending - waiting for next available executor" and the job it is triggered with some webhook after pushing changes to GIT Developers may not notice that theirs expected jobs will not run until they manually check the job and release or cancel the one give them issues.

          Daniel Alejandro Hernández added a comment - Hi oleg_nenashev mansoor I have give it a try and it still working fine the expected scenario. Just a few comments with a common scenario: When you run a job with a user that has no grant over the Node to run jobs there so the job will be queued or stuck with the label "pending - waiting for next available executor". Then if a different user try to run the same job but has the correct grants further job will not run until manually stop or cancel previous job and then trigger the new ones. I did check that the job can run concurrent builds and the Node has enough executors and regardless that the new builds cannot run until manually release the one that is "pending - waiting for next available executor" status. So with this miss behaviors can arise, for instance if there a job with the status "pending - waiting for next available executor" and the job it is triggered with some webhook after pushing changes to GIT Developers may not notice that theirs expected jobs will not run until they manually check the job and release or cancel the one give them issues.

          Mansoor Saqib added a comment -

          Hello daniel_alejandro_hc ,

          Thank you for the reply. I don't know the reasons for the default behavior and oleg_nenashev could provide it, but for our purposes this works great when using it for pipeline jobs.

          I have tried the scenario that you've outlined above with freestyle type jobs and you're correct. When using freestyle jobs for example it does indeed hang if a non restricted user runs a build, it doesn't let a restricted user's builds through without first removing this hanging job from the previous user. I will try to come up with a solution but it may be a problem that is not within the scope of this current issue I believe. It may need another issue created for it that oleg_nenashev could possibly look at. However it is an interesting scenario and I'll be sure to try to provide some workaround or solution if I can.

          I appreciate the help and feedback daniel_alejandro_hc , thanks.

          Mansoor Saqib added a comment - Hello daniel_alejandro_hc , Thank you for the reply. I don't know the reasons for the default behavior and oleg_nenashev could provide it, but for our purposes this works great when using it for pipeline jobs. I have tried the scenario that you've outlined above with freestyle type jobs and you're correct. When using freestyle jobs for example it does indeed hang if a non restricted user runs a build, it doesn't let a restricted user's builds through without first removing this hanging job from the previous user. I will try to come up with a solution but it may be a problem that is not within the scope of this current issue I believe. It may need another issue created for it that oleg_nenashev could possibly look at. However it is an interesting scenario and I'll be sure to try to provide some workaround or solution if I can. I appreciate the help and feedback daniel_alejandro_hc , thanks.

          Oleg Nenashev added a comment -

          When I was working on the plugin, there was no valid way to cancel the job execution from Job Properties when there are no suitable executors. It becomes even more complicated with Cloud API plugins, because Jenkins NEVER knows which labels can be provided by Cloud plugins, and there are some plugins which really have dynamic lists of supported labels (private-source example: cloud for provisioning shared agents/clouds in CloudBees Jenkins Operations Center). I implemented the current behavior for starters, but there are real use-cases for the current behavior.

          Adding support of build termination is doable, but it likely has to be done by another plugin or the core itself. Job Restrictions are just a single case of a wider issue (e.g. Label Restrictions, Throttle Concurrent Builds, etc., etc.).

          Oleg Nenashev added a comment - When I was working on the plugin, there was no valid way to cancel the job execution from Job Properties when there are no suitable executors. It becomes even more complicated with Cloud API plugins, because Jenkins NEVER knows which labels can be provided by Cloud plugins, and there are some plugins which really have dynamic lists of supported labels (private-source example: cloud for provisioning shared agents/clouds in CloudBees Jenkins Operations Center). I implemented the current behavior for starters, but there are real use-cases for the current behavior. Adding support of build termination is doable, but it likely has to be done by another plugin or the core itself. Job Restrictions are just a single case of a wider issue (e.g. Label Restrictions, Throttle Concurrent Builds, etc., etc.).

          The last update was a year ago, any update? This is one key thing that is holding us back from pinning nodes to certain users so we don't have to use a power user to connect to the nodes and then restrict who can use the node.

          Michael DeGuzis added a comment - The last update was a year ago, any update? This is one key thing that is holding us back from pinning nodes to certain users so we don't have to use a power user to connect to the nodes and then restrict who can use the node.

          Oleg Nenashev added a comment -

          No update. The described use-case can be rather done by Authorize Project and user roles  in matrix-auth/role-strategy

          Oleg Nenashev added a comment - No update. The described use-case can be rather done by Authorize Project and user roles  in matrix-auth/role-strategy

          Hmm ok, I will check into that. I was hoping to restrict this at the node level. I'm not entirely sure how to achieve this with that plugin, but maybe I missed something.

          Michael DeGuzis added a comment - Hmm ok, I will check into that. I was hoping to restrict this at the node level. I'm not entirely sure how to achieve this with that plugin, but maybe I missed something.

          I don't really see a way to restrict nodes with Authorize Project. Any notes on that or a post that describes that?

          Michael DeGuzis added a comment - I don't really see a way to restrict nodes with Authorize Project. Any notes on that or a post that describes that?

          I do not see the way how to do it in role-strategy as well. I need to restrict execution on certain Agents for certain people or groups and it is not possible to achieve it in standard authorisation method. In role-strategy I am able to not to allow build for certain group or people, but I want them to execute builds, but not on all agents

          Ladislav Toldy added a comment - I do not see the way how to do it in role-strategy as well. I need to restrict execution on certain Agents for certain people or groups and it is not possible to achieve it in standard authorisation method. In role-strategy I am able to not to allow build for certain group or people, but I want them to execute builds, but not on all agents

          I have tried the version in attachment, job-restrictions.hpiand it works for my use case thanks mansoor, solving my problems (restrict execution only for certain groups). Build termination was not requested in this ticket, is there a vision of releasing this fix officially?

          Ladislav Toldy added a comment - I have tried the version in attachment, job-restrictions.hpi and it works for my use case thanks mansoor , solving my problems (restrict execution only for certain groups). Build termination was not requested in this ticket, is there a vision of releasing this fix officially?

            mansoor Mansoor Saqib
            daniel_alejandro_hc Daniel Hernandez
            Votes:
            21 Vote for this issue
            Watchers:
            25 Start watching this issue

              Created:
              Updated: