Manage GitHub teams permissions as code #3998

Alaurant · 2024-07-07T16:23:43Z

This Pull Request enhances the process for managing team permissions. It automates the synchronization of team data, ensuring our GitHub records are always up-to-date.

Key Features

Repository Permission Updates: Once the PR is merged, it updates the team and sends an invitation if needed.

Automatic Sync: it runs every week to ensure the files’ data is in sync with the live data on GitHub.

timja

Some initial feedback, what testing has been done on this?

...a/io/jenkins/infra/repository_permissions_updater/github_team_sync/GithubTeamDefinition.java

src/main/java/io/jenkins/infra/repository_permissions_updater/github_team_sync/TeamUpdater.java

...ain/java/io/jenkins/infra/repository_permissions_updater/github_team_sync/YmlTeamLoader.java

timja · 2024-07-21T16:05:46Z

...ain/java/io/jenkins/infra/repository_permissions_updater/github_team_sync/YmlTeamLoader.java

+                repoPath = (String) data.get("github");
+            }
+
+            if (data.containsKey("github_team")) {


do we think we need to add this / need it as the only way?

teams are currently done by the repository name and should be easily determinable, (there may be some outliers though and where it might be good to be able to override this)

Currently, if a YAML file doesn't include github_team, I don't take any action.
If it does include github_team, I assume there's a unique team name like github_team: abc_team, and update the developers on that team.

However, based on your description, it seems uncommon to have a unique team name specified. Is it more common for github_team to be included without a specific name, meaning the team name would default to the repository name?

Also, if I have misunderstood anything in the first part, please correct me.

it will currently never include a GitHub team you will need to backfill those across the repository with this approach.

(not necessarily a bad thing)

Teams will almost always be unique per repository, occasionally there will be additional teams with access.

e.g. design-library-plugin has the sig-ux team with access.

and there will be other similar examples

e.g. design-library-plugin has the sig-ux team with access.

In particular, while most teams are ${repo}-developers, there are some "special" teams spanning multiple repositories.

Also, I don't see where team repos are being managed, only team members. Would those special teams be excluded from management as code?

Similarly, this also hardcodes push permission, when there are cases where the permissions should be different. Are those also excluded?

I would suggest for non-schema based groups that in the future it is moved to an extra section called: custom-groups.

It needs to be done before go-live of the new solution, ideally as close to when the other solution is ready to merge in case changes occur again.

I've set up a new repository for the one-off backfill and updated the README with the current backfill logic and a few questions. When you have a moment, I'd appreciate it if you could take a look: https://github.com/Alaurant/OneOffSyncTool.

Extended Permissions

You should be able to see all GitHub permissions with this report which might help with your permissions request: https://reports.jenkins.io/github-jenkinsci-permissions-report.json

Format

I wouldn't use the empty string if you can't match a person: github: "", just omit the key.

Clarification of Special Teams:

I'm not sure what you mean by clarification of special teams, yes its name is SIG: UX

Challenges with Multiple YAML Files for a Single Repository

I think only one file should be managing the GitHub permissions ideally good point

Thank you for your patience in reading and responding. The permissions report will be helpful.

Format

Following your advice to omit the key, would the entries look like this?

- ldap: Alice - github: Bob - ldap: Chalie github: Chalie

Clarification of Special Teams:

I appreciate your help on the "SIG: UX" clarification. Could you confirm if the following matches are correct?

cloudbees-developers: company-cloudbees-developers

core: Core or Core PR Reviewers?

security: core-security-review

openshift-developers: Which team corresponds to this in the provided image?

Thank you again.

Yes entries would look like that

yes cloudbees is company-cloudbees...

core is Core

I don't think security is core-security-review, they are separate

there's no openshift-developers team in GitHub but I'm sure it would be a good idea.

daniel-beck

It is unclear to me what this is trying to accomplish and why it is added to this repository.

daniel-beck · 2024-07-21T17:44:09Z

.github/workflows/teamsync_update_automatically.yml

+    - name: Build project
+      run: mvn clean install
+
+    - name: Update all yml files in permissions directory


This message appears to be misleading, as it claims to modify yml files, rather than use them as a reference (which seems to be what YmlTeamLoader#loadTeam does).

daniel-beck · 2024-07-21T17:45:49Z

.github/workflows/teamsync_check_for_changes.yml

+      id: files
+      run: |
+        echo "Checking for changes in permissions/*.yml files..."
+        FILES=$(git diff --name-only ${{ github.event.before }} ${{ github.sha }} -- 'permissions/*.yml')


This relies on every single execution being successful (assuming no infra trouble ever), which seems unsafe.

There's a sweeper that runs once per week, I umm'ed and erred on this. Only operating on changes files will certainly be quicker, but why re-invent the wheel instead of using something like terraform which can maintain the state?

Wouldn't terraform be a bit over the top for this PR?

its a standard infra as code tool, rather than re-implementing the wheel, it allows more people to collaborate especially from e.g. the infra team.

.github/workflows/teamsync_check_for_changes.yml

Co-authored-by: Tim Jacomb <[email protected]>

This reverts commit 5e3d6af.

Alaurant and others added 6 commits July 7, 2024 22:25

add team sync function

f100edb

fix upper case issue

d2e1f1a

Rename yamlTeamLoader.java to YAMLTeamLoader.java

4d25a7b

fix safe path

59b6820

change file type

632e24e

change workflow path

1a7ce9f

Alaurant requested a review from a team as a code owner July 7, 2024 16:23

NotMyFault requested review from NotMyFault and timja July 20, 2024 14:20

timja reviewed Jul 21, 2024

View reviewed changes

timja requested review from Wadeck and daniel-beck July 21, 2024 16:07

daniel-beck reviewed Jul 21, 2024

View reviewed changes

Alaurant and others added 3 commits July 22, 2024 12:25

Update naming conventions

ca4e835

Co-authored-by: Tim Jacomb <[email protected]>

Update variable names

a7b86fd

Co-authored-by: Tim Jacomb <[email protected]>

Update related variable names

3674be9

Co-authored-by: Tim Jacomb <[email protected]>

Alaurant marked this pull request as draft July 22, 2024 02:34

Alaurant and others added 13 commits July 29, 2024 11:21

Update funcs based on feedback

3654aff

Merge branch 'jenkins-infra:master' into master

5da05b9

update definition file

1c15445

update definition name

7a853aa

remove system exit

ecad765

Fix case sensitivity issues in filenames

93d4959

Remove unwanted file with incorrect case

bb6369c

new features

d02abbb

Merge branch 'jenkins-infra:master' into master

9305041

remove first run check

2138e2d

Merge branch 'jenkins-infra:master' into master

6a11556

Merge branch 'feature'

45a2b0f

fix the problem of static method

5e3d6af

Alaurant and others added 5 commits August 26, 2024 22:15

Revert "fix the problem of static method"

c3f766d

This reverts commit 5e3d6af.

Provide a default or empty file path

c8993bd

update static method

e24ecda

Merge branch 'jenkins-infra:master' into master

3f0fc8f

Merge branch 'jenkins-infra:master' into master

9d7a0aa

Alaurant mentioned this pull request Sep 14, 2024

One-Off Backfill Tool for Managing GitHub Permissions as Code #4091

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Manage GitHub teams permissions as code #3998

Manage GitHub teams permissions as code #3998

Alaurant commented Jul 7, 2024

timja left a comment

timja Jul 21, 2024

Alaurant Jul 23, 2024

timja Jul 23, 2024

daniel-beck Jul 23, 2024 •

edited

Loading

TheMeinerLP Aug 6, 2024

timja Aug 25, 2024

Alaurant Sep 9, 2024

timja Sep 10, 2024

Alaurant Sep 10, 2024

timja Sep 11, 2024

daniel-beck left a comment

daniel-beck Jul 21, 2024

daniel-beck Jul 21, 2024

timja Jul 21, 2024

NotMyFault Aug 5, 2024

timja Aug 5, 2024

Manage GitHub teams permissions as code #3998

Are you sure you want to change the base?

Manage GitHub teams permissions as code #3998

Conversation

Alaurant commented Jul 7, 2024

Key Features

timja left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daniel-beck Jul 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daniel-beck left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daniel-beck Jul 23, 2024 •

edited

Loading