-
Notifications
You must be signed in to change notification settings - Fork 529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only fetch job queue in getCauseOfBlockage #2568
base: master
Are you sure you want to change the base?
Only fetch job queue in getCauseOfBlockage #2568
Conversation
Hi, |
ab5f39a
to
4c28f5d
Compare
Thx for looking into it. I replaced the approach by getting the items from a different list which does not check permissions and all tests are passing now. |
4c28f5d
to
2f47cfc
Compare
@olamy |
any feedback pls? |
Hi, |
@schiasileon checking permissions is on purpose (see https://www.jenkins.io/security/advisory/2015-11-11/#queue-api-did-show-items-not-visible-to-the-current-user) |
Hi, I cannot see where permissions would matter in this context. You are just looking for a Item the user already has access to to get cause of blockage. |
Description
This fixes a performance issue on large Jenkins instances with huge queues.
Before this fix, blueocean would fetch all Jenkins queue items when cause of blockage is needed just to find out which item the run belongs to. While doing this, Jenkins has to execute a permission check on all queued Items, possibly leading to performance issues.
We documented and tested this issue on one of our Jenkins instances with 1000+ queue items. The permission check lead to the azure-ad plugin taking up a lot of CPU. Also see previous fix attempts here.
Unit test not needed as this doesn't change any behavior.
Submitter checklist
Reviewer checklist