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

Locks should be scoped - multi Tennant problem

XMLWordPrintable

      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?

            Unassigned Unassigned
            johnlonergan John Lonergan
            Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: