jenkinsci / jenkinsci/lockable-resources-plugin

[JENKINS-51725] Locks should be scoped - multi Tennant problem

Open
#908 1 comment 0 reactions 0 assignees View on GitHub
component:lockable-resources-plugin imported-jira-issue priority:minor resolution:unresolved Triage
Dominant language
Java
Stars
99
Forks
205
Avg merge
2d 13h
Merged PRs (30d)
8

Description

Locks should be scoped so that one team's lock names don't accidentally collide with another's?

Pipeline locks seem to be created on demand (no need to precreate) at server level rather than at folder level or job level.

Right now I'm telling folk to be careful with naming but this is a poor solution for an instance that 100s of Devs use.

Best to consider scoping of objects wholistically.

Why should anything have to be at global scope only?

Does Jenkins have a documented strategy for scoping and ownership or is it adhoc?

More generally... from a resource management point of view it would seem that Jenkins would benefit from all objects being scopeable to something narrower than global as this would reduce the admin burden and improve self service without increasing risk. Folder names are of course inherently scoped, and credentials can also be created at folder scope, but what about node names and labels, or any other such objects, why do they have to be global?

And then we can also talk about permissions. Who should be permitted to obtain a given lock and who not?

---
Originally reported by johnlonergan, imported from: Locks should be scoped - multi Tennant problem


  • status: Open
  • priority: Minor
  • component(s): lockable-resources-plugin
  • resolution: Unresolved
  • votes: 3
  • watchers: 3
  • imported: 20251217-081411

Raw content of original issue

Locks should be scoped so that one team's lock names don't accidentally collide with another's?

Pipeline locks seem to be created on demand (no need to precreate) at server level rather than at folder level or job level.

Right now I'm telling folk to be careful with naming but this is a poor solution for an instance that 100s of Devs use.

Best to consider scoping of objects wholistically.
Why should anything have to be at global scope only?
Does Jenkins have a documented strategy for scoping and ownership or is it adhoc?

More generally... from a resource management point of view it would seem that Jenkins would benefit from all objects being scopeable to something narrower than global as this would reduce the admin burden and improve self service without increasing risk. Folder names are of course inherently scoped, and credentials can also be created at folder scope, but what about node names and labels, or any other such objects, why do they have to be global?

And then we can also talk about permissions. Who should be permitted to obtain a given lock and who not?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.