You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature would be off by default. If configured on, this feature would attempt to lock a resource. If the resource is busy the build would be added to the resource queue and would be kicked back out to the second position in the build queue allowing the next build to be sent to the now available executor. Once this build is in the resource queue, before leaving the build queue it would check to see if the resource is still locked. If it is still locked then the build is moved to second in the queue allowing the next build to be sent to the available executor. This would prevent multiple jobs that need the same limited resource from taking all available executors and then spinning while waiting for the resource to be available.
Upstream changes
No response
Are you interested in contributing this feature?
Yes, I would be more than happy to contribute to this issue. This would be my first time contributing and I am not exactly sure where to start with it.
The text was updated successfully, but these errors were encountered:
@mPokornyETM I don't think that is what @epiq-ben meant. I think he wants the same feature that I am looking for:
When I have an agent with 5 executors where 1 is running and the 4 others are waiting for a resource locked by the 1st job, all 4 waiting jobs should be removed from the executors and put back in the queue. This way other jobs that may have been waiting to start can actually run instead of everybody waiting for a single job.
We are having this issue, where eg in a multi-branch job several of our executors are blocked with waiting for a lockable resource. If we could somehow move these jobs back in the queue (or maybe some special queue, since the jobs might have to go back to the exact same node) we could actually use the agent to the fullest instead of just wasting the executors by being idle.
What feature do you want to see added?
This feature would be off by default. If configured on, this feature would attempt to lock a resource. If the resource is busy the build would be added to the resource queue and would be kicked back out to the second position in the build queue allowing the next build to be sent to the now available executor. Once this build is in the resource queue, before leaving the build queue it would check to see if the resource is still locked. If it is still locked then the build is moved to second in the queue allowing the next build to be sent to the available executor. This would prevent multiple jobs that need the same limited resource from taking all available executors and then spinning while waiting for the resource to be available.
Upstream changes
No response
Are you interested in contributing this feature?
Yes, I would be more than happy to contribute to this issue. This would be my first time contributing and I am not exactly sure where to start with it.
The text was updated successfully, but these errors were encountered: