-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc On 16/06/17 07:55, Fabian Arrotin wrote: > On 16/06/17 08:09, Vinzenz Feenstra wrote: >> Hi, >> >> Our team uses the CentOS CI infrastructure together within GitHub PR to check those to be in shape. >> At times it happens that due to programming mistakes we would like to cancel/abort jobs. As those runs take usually up to 45 minutes or even longer or sometimes are just stuck because they are waiting for user input that ofc never is going to happen. >> >> Is there some way to stop them? >> >> In this particular case I am talking about the leapp-to project @ github ( https://github.com/leapp-to/prototype ) >> >> Thanks >> >> -- >> Vinzenz Feenstra >> Senior Software Developer >> Red Hat Czech > > Hi, > > When we started the CI project, Jenkins was configured to use its > internal auth DB for users/groups. Jenkins let fine tune rights and > there is one like Job/Cancel that can be granted. It was after a certain > time decided to not create users/groups anymore at the Jenkins level to > let $projects create their jobs, but rather use JJB so that $projects > would not have to do anything on Jenkins itself, but their jobs would be > added/updated/etc through PR for JJB > > With that specific use case in mind, I'm wondering if the best way would > not to be linking jenkins with https://accounts.centos.org for > authentication/group membership. > Jenkins supports SSO through openid, which we already have in place for ACO. > > For example, for the QA team, we have another jenkins setup (different > from the CI env) that is using ACO as authentication source, so people > are authenticated through SSO/OpenID > > Would it be useful to consider doing the same for CI ? From my personal > side, it would make sense to reflect all accounts/users/groups/rights at > a single place (SSO FTW) and "just" use it transparently within Jenkins > > Not an expert in Jenkins though, so maybe there are other alternatives > for that. > > Opinions on this ? > I think we should spend a bit more time and workout the goal post here - for one, I would like to see user accounts removed as much as possible from jenkins, and we move increasingly towards either pipelines or automation around legacy like work flows. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc