On Thursday, 8 August 2013 20:08:54 UTC+1, LesMikesell wrote: > > On Thu, Aug 8, 2013 at 12:31 PM, Stephen Connolly > <[email protected] <javascript:>> wrote: > >> > >> Scoping by the user creating the job would make more sense to me, > >> although I'm not sure how strictly jenkins could enforce that. > > > > > > What happens if a different user edits the job? > > I guess my answer would depend on how badly this other user is going > to abuse my credentials... Maybe an option to invalidate them on a > change by a different use would be good. Not sure how often the > inconvenience would be worth the trouble. > > I think a better solution would be to give you a non-manage jenkins screen where you can put your credentials you want useable by others. The per-user ones are really for actions that we can always confirm are actioned by that user.
> > I can certainly allow selecting from users own credentials... But that > will > > restrict when the job can build. > > Can't you allow a user to stash an assortment of urls with credentials > to match, then pick the most specific match when you need it - maybe > falling back to job, folder, or system defaults or taking the most > specific you can find in any of those? > That kind of ends up being unpredictable and people will just not trust that Jenkins "does the right thing"... I don't want to start down such a road... the current Subversion authentication madness is the result of such an approach > > > I can think of a semi-fixed job property that defines the "default" > owner > > for SCM backed changes... Then when the job is triggered by a user we > pick > > their credentials if they don't have access to the corresponding > > credentials... But given that these are credentials with a UUID based > ID, > > we'd probably need to turn the credentials required into parameters, > > essentially making the job parameterized. > > > > That all gets really complex... Hence my preference for scoping > credentials > > to folders > > Since I'm not using folders I can't think of any way they relate (or > should) to credentials. > I think you are missing out. Folders are not views. A job belongs to a folder. The credentials API will walk up the tree of owners asking them to contribute to the list of available credentials. So you can store credentials not just at the root, but also in a folder or a sub-folder, or a sub-sub-folder. So instead of having 10 jobs at the root for the FooBar project, you create a FooBar folder, grant control to do things in that folder to the team that are working on the FooBar project, and let them store the credentials that their jobs need to do in their folder.... all scoped nicely > > > On the other hand Kohsuke and Jesse have been pursuing running builds in > the > > context of the user that triggered them, so they may have some other > > suggestions (plus I have dared them to integrate credentials with GIT > and HG > > respectively, so this is a problem they face too) > > 'User that triggered' is an odd concept for scheduled stuff - weirdly > intertwined with the user that made a commit that affects the job > (perhaps the actual script that runs the build), and there's no > general assumption you can make about the user ids across the VCS, > jenkins master, or jenkins slave where things run. > Never said I agreed with the KK/JG plan... only that they have some ideas that way... but they cannot yet explain how the model will actually work in a meaningful way... so I think they're on a loosing plan, but I'll give them the benefit of the doubt for now ;-) > > -- > Les Mikesell > [email protected] <javascript:> > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
