It'd be good if a job could be set up to completely block an entire category. Use-case for this would be having a "writer" job that e.g. updates a server, and having a set of "reader" jobs that contact that server. The "writer" job would completely block the "use-server" category from running any concurrent builds, and the "reader" jobs would just use 1 slot of the allocated slots for that category.

          [JENKINS-12092] Allow a job to completely block a category

          I think the ideal way to solve this is to have a multi-project throttle category that you assign to all your jobs.
          The multi-project throttle category should be able to have high limitations or no limitations at all.

          If you then create:
          jobA and jobB with the limitations 0/0 they should be able to run concurrently up to the multi-project throttle category limitations.
          jobC with the limitations 1 per node, jobC should only run on a node if no other job with the throttle category runs on the node.
          jobD with the limitations 1 in total, jobD should only run if no other jobs of this category is running.

          The UI to support this is already there, I have tried to set this up since I thought that it should work before I saw this issue

          Christian Bremer added a comment - I think the ideal way to solve this is to have a multi-project throttle category that you assign to all your jobs. The multi-project throttle category should be able to have high limitations or no limitations at all. If you then create: jobA and jobB with the limitations 0/0 they should be able to run concurrently up to the multi-project throttle category limitations. jobC with the limitations 1 per node, jobC should only run on a node if no other job with the throttle category runs on the node. jobD with the limitations 1 in total, jobD should only run if no other jobs of this category is running. The UI to support this is already there, I have tried to set this up since I thought that it should work before I saw this issue

          Christian Bremer added a comment - 300$ is up for grabs for solving this issue at: https://freedomsponsors.org/issue/618/allow-a-job-to-completely-block-a-category?alert=SPONSOR#

          Seán Dunne added a comment -

          Hi Christian,

          I don't believe the UI that's presented in the jobs configuration is there for this purpose. As far as I can see, if you select Throttle this project as part of one or more categories the 2 Maximum Concurrent Builds textboxes are ignored. Those textboxes are only used when the Throttle this project alone radio is selected.
          At least, from my limited understanding of the plugin that's how it works.

          I've been spending a bit of time on this issue.
          The solution I have implemented so far is,

          • I added a new checkbox that belongs to the Throttle this project as part of one or more categories radio
          • The new checkbox Let this Job be blocked by selected Categories (it's a working title) will block a job if any builds from any of the selected categories are queued or executing

          This in effect lets you select 1 or more jobs that will not execute while jobs from it's categories are executing.
          What do you think of this solution?
          I'd like to get some community feedback before I make a pull request.
          Thanks!

          P.S:
          I was also considering fixing the UI so the "child" options only show up when you select it's parent radio button. But that's part of a different issue.

          Seán Dunne added a comment - Hi Christian, I don't believe the UI that's presented in the jobs configuration is there for this purpose. As far as I can see, if you select Throttle this project as part of one or more categories the 2 Maximum Concurrent Builds textboxes are ignored. Those textboxes are only used when the Throttle this project alone radio is selected. At least, from my limited understanding of the plugin that's how it works. I've been spending a bit of time on this issue. The solution I have implemented so far is, I added a new checkbox that belongs to the Throttle this project as part of one or more categories radio The new checkbox Let this Job be blocked by selected Categories (it's a working title) will block a job if any builds from any of the selected categories are queued or executing This in effect lets you select 1 or more jobs that will not execute while jobs from it's categories are executing. What do you think of this solution? I'd like to get some community feedback before I make a pull request. Thanks! P.S: I was also considering fixing the UI so the "child" options only show up when you select it's parent radio button. But that's part of a different issue.

          Hi Seán,

          Thanks for looking into this.

          What I am missing from your solution is the ability to throttle to 1 instance per-node not only on a global level.

          I think that it would be more dynamic if the original UI boxes could be used and that one could use 1 per node or 1 in total or any other combination of node/total that is lower than the category limit.
          Since we don't need it currently it's not needed but nice-to-have.

          Christian Bremer added a comment - Hi Seán, Thanks for looking into this. What I am missing from your solution is the ability to throttle to 1 instance per-node not only on a global level. I think that it would be more dynamic if the original UI boxes could be used and that one could use 1 per node or 1 in total or any other combination of node/total that is lower than the category limit. Since we don't need it currently it's not needed but nice-to-have.

          Seán Dunne added a comment -

          Thanks for the feedback Christian!

          I don't know if using the threshold inputs on the Job configuration page is the right place to do this.

          But I think we could implement this same support by moving the "blocking" part from the Job configuration into the Global configuration where we define the Categories. If we allowed category B to be blocked by category A.
          This way we could allow category A to completely block all jobs in category B from executing until all queued jobs from category A have completed.

          This would allow both categories to have their own separate throttle limits which would not interfere with each other.

          Seán Dunne added a comment - Thanks for the feedback Christian! I don't know if using the threshold inputs on the Job configuration page is the right place to do this. But I think we could implement this same support by moving the "blocking" part from the Job configuration into the Global configuration where we define the Categories. If we allowed category B to be blocked by category A. This way we could allow category A to completely block all jobs in category B from executing until all queued jobs from category A have completed. This would allow both categories to have their own separate throttle limits which would not interfere with each other.

          That sounds like an good idea Seán.

          Christian Bremer added a comment - That sounds like an good idea Seán.

          Seán Dunne added a comment -

          Seán Dunne added a comment - Pull request made. https://github.com/jenkinsci/throttle-concurrent-builds-plugin/pull/25

          Sean, are you working on resolving the merge conflicts to get it into the repo?

          Christian Bremer added a comment - Sean, are you working on resolving the merge conflicts to get it into the repo?

          Seán Dunne added a comment -

          Not right now.
          I will eventually, once I get the time.

          Seán Dunne added a comment - Not right now. I will eventually, once I get the time.

          Seán Dunne added a comment -

          Hi Christian,

          I've resolved the conflicts and fixed an upgrade issue I missed the first time around. The PR is ready for review now

          /Seán

          Seán Dunne added a comment - Hi Christian, I've resolved the conflicts and fixed an upgrade issue I missed the first time around. The PR is ready for review now /Seán

            Unassigned Unassigned
            jorgenpt Jørgen Tjernø
            Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: