Openjdk-infrastructure: Revisit github teams in the project and what they control

[sxa]

I've been looking at some of the teams that we have and what they get access to and a few things have stood out:

1. We don't have too much consistency in the naming of the teams
2. We don't have a group that lets people triage builds that gives them access to the signing job logs
3. We have a number of jobs where the permissions seem to have unnecessarily listed individuals listed against things instead of teams

I've copied some of this from the infrastructure and build FAQs but I'll add more as I put them together:

Infrastructure

• adoptopenjdk-infrastructure - write access to the repository which lets you be an official approver of PRs (triage doesn't)
• infrastructure - higher level of access for system administrators only
• admin_infrastructure - The Admin team - can force through changes without approval etc.

Build

• GetOpenJDK - Triage level of access which lets you assign issues to people
• build - Write access which lets you approve and merge PRs and run and configure most jenkins jobs
• release - Allows you to run the release jobs in jenkins

Test

• testing - Write access which lets you approve and merge PRs and run and configure most jenkins jobs (to 5 test repos, bumblebench, openjdk-systemtest, openjdk-tests, stf, openjdk-test-tools)
• coretest - write access to TKG repo

Other groups:

• icedtea-web
• installer
• jenkins-admins
• Jitwatch
• jsplitpkgscan
• openjdk-upstream-binaries
• openjdk-upstream-binary-rel-eng

[jerboaa]

openjdk-upstream-binaries (admin group)
openjdk-upstream-binary-rel-eng (write group)

These two are for the OpenJDK Project Builds work we do in openjdk8-upstream-binaries and openjdk11-upstream-binaries.

[sxa]

For the main repos I'm going to propose the following updates for now. Putting build infrastructure and test means they'll be easier to collate in a sorted list. I'm somewhat in two minds about build-core. I'd possibly prefer infra to infrastructure but since I'm not going to be typing it too frequently I'm also ok with the full version:

| Current team name | New name | Access level | Other change? |
|---|---|---|---|
| GetOpenJDK | build-triage | | Should we let triagers re-run builds? |
| build | build | Can run builds | |
| | build-core | Visibility of install/sign jobs | Will remove lots of custom access |
| | infrastructure-triage | Only triage access | For new people to the team |
| adoptopenjdk-infrastructure | infrastructure | Can approve PRs | |
| admin_infrastructure | infrastructure-core | Jenkins agent control | Lose secrets access |
| infrastructure | infrastructure-secret | Access to secrets repo | |
| | test-triage | own issues, run Grinders | (Grinders currently unrestricted) |
| testing | test | | |
| coretest | test-core | Access to TKG repo | |

Broad summary of what the above is intended to achieve for each area of the project:

• -triage suffixed ones for anyone who turns up and thinks they can help with something. Little real access
• unsuffixed version for team members who are committers and have the ability to approve/merge PRs
• -core suffixed ones for higher level access of some sort

[sxa]

@AdoptOpenJDK/tsc previous comment for review. Renaming will "lose" any at-mentions to the old team but I don't think we really use those for the affected ones. My plan would be to rename, and update any jenkins jobs which are acces-controlled by the old name, as well as implementing the new build-core group.

[aahlenst]

I'm happy with the proposed changes.

[smlambert]

I would like to reduce the number of members in the testing group, they were originally added to enable a larger set of people to be able to run Grinders, as that seemed to be the mechanism used to control access. I can go in and cull many of the names in the testing group, as there are many names that are not active there.

[sxa]

Agreed @smlambert - I need to do the same with the others but I felt that rationalising them so I could figure out what the groups were for first was a prereqs (Luckily you only have two so less of a problem!) :-)

[gdams]

+1

[karianna]

The list looks good, was thinking about build-triage --> support but I'm not too fussed

[tellison]

Top level repo names look good, and as for the suffixes...

-triage suffixed ones for anyone who turns up and thinks they can help with something. Little real access
unsuffixed version for team members who are committers and have the ability to approve/merge PRs
-core suffixed ones for higher level access of some sort

how about, rather than 'unsuffixed', you use -team, so we end up with, for example, build-triage, build-team, build-core which would be explicit.

[sxa]

@karianna Yeah I can see why we'd call it "support", although this is primarily for access to the build repository and I wanted to make the names be related to the main repo they're for, at least for now.

@tellison I suppose my only thought would be "Would triagers not think they're part of a team" and they're all teams (So you'd have "the build-team team" but I can see how some sort of suffix might be useful too. Definitely one I'm not personally concerned with either way though. Perhaps a suffix of -committers might be more descriptive (other than the fact that's not necessarily descriptive with respect to running extra jenkins jobs that level may have access to over triage)

[sxa]

All build and infrastructure ones now renamed. We need to revisit what is now openjdk-triage as it had write access to quite a few other repositories so that will need a separate sanitisation. I suspect we'll create a replacement for getOpenJDK which has a cleaner set of permissions and users in it and restrict openjdk-triage down to just the build repos.

Installer/sigfning jobs have been updated with the new permissions so permissions on those jobs are using the team instead of multiple individual users beign explicitly specified

[sxa]

Test teams renamed as described above too - new test-triage group created with triage (not write) access to the test repos. We should look at the ACLs on the Grinder jobs too.

For now I'm going to consider this closed, although future adjustments to this can be iterative (and potentially documented in here)

[sxa]

(Minor change of plan - I've put getOpenJDK back to it's original name and created a new build-triage team)