[INFRA-946] Jenkins instance: create a folder for remoting automation and grant people access there

[jenkins-infra-bot]

CC R. Tyler Croy

Likely we will have several jobs for remoting at some point. It would be great to have an project folder, where remoting devs would be able to create/manage their automation.

People, which should have Job create/configure/run permissions in the folder

• Oleg Nenashev
• Stephen Connolly
• James Nord
• R. Tyler Croy

---

Originally reported by oleg_nenashev, imported from: Jenkins instance: create a folder for remoting automation and grant people access there

• assignee: oleg_nenashev
• status: Closed
• priority: Major
• resolution: Fixed
• resolved: 2017-09-02T23:00:44+02:00
• imported: 2022/01/10

[jenkins-infra-bot]

rtyler:

Oleg Nenashev, I can create a remoting GitHub Organization Folder. I am not going to create any project matrix authorization configuration since (and freestyle jobs), that ended up being such a mess with our last primary Jenkins instance.

With a list of repositories I can easily create the GitHub Org Folder though.

The 'Run' permission is something we should definitely have for logged in users and currently don't.

[jenkins-infra-bot]

oleg_nenashev:

Maybe I'm a bit Jenkins-1-minded, but I still want to create multiple jobs for a single repository: Common Multi-branch for the Repo, extra prototyping and advanced testing jobs (e.g. "Bleeding edge" for components, tests for dependent components like Docker slaves, etc).
I do not see how these case can be integrated via a single maintainable Pipeline. GitHub Org Folder and Pipeline Multibranch are not applicable for such case.

[jenkins-infra-bot]

oleg_nenashev:

If Matrix Configuration is too complex for this case, I can help with setting up the Ownership-based security.
https://speakerdeck.com/onenashev/jw2016-ownership-plugin-demo

[jenkins-infra-bot]

rtyler:

Oleg Nenashev, there is nothing you describe that doesn't sound to me like it's not solvable with Pipeline in some form or another. I know that Christopher Orr was looking for solutions his, even more complicated, requirements.

As for the Ownership plugin, the problem is not a lack of tools to solve authorization. The problem is that we have *far* too many different authorization and authentication lists in the Jenkins project and they are both difficult to maintain but quickly become out of date. Relying on commit access to a GitHub repository (i.e. Jenkinsfile) allows me to remove Daniel Beck and myself from the equation of CI authentication/authorization entirely.

Finally, I simply will not allow freestyle job configuration/editing again. It is a fundamentally unmaintainable practice at any non-trivial scale in Jenkins. So the options available would be Pipeline (as previously mentioned) or something like Jenkins Job Builder or the Job DSL plugin.

[jenkins-infra-bot]

rtyler:

Awaiting feedback from Oleg to move forward here

[jenkins-infra-bot]

oleg_nenashev:

R. Tyler Croy the old use-cases make no sense anymore.

I think the folder could be still useful since Remoting is a sub-project && We need to setup automatic builds of Docker packages for Remoting, but it's a long shot since I have no capacity for that.

[jenkins-infra-bot]

oleg_nenashev:

Docker builds would also go to Trusted CI, I'd guess

[jenkins-infra-bot]

oleg_nenashev:

Not required so far