Peribolos does not support new Github team repo permissions

[coverprice]

What happened:
When dumping the Peribolos config skeleton for a Github org that contains a team with the beta Triage or Maintain permissions on a repo, the repo is dumped with permission none, which is invalid.

e.g.

$ peribolos --github-token-path=/token --dump some-github-org --dump-full
    [snip]
    team-foo:
        [snip]
        members:
        - someuser
        privacy: secret
        repos:
          somerepo: none           <------------ team-foo has permission 'Maintain' on somerepo.
          someotherrepo: read
        [snip]

What you expected to happen:
The repo is listed with the correct permission (presumably triage or maintain)

How to reproduce it (as minimally and precisely as possible):

1. Assign any Github team to a repo, and grant it Triage or Maintain permissions.
2. Run the Peribolos dump script on the organization (see above for an example)

Please provide links to example occurrences, if any:

Anything else we need to know?:
I don't know whether it's necessary to only fix the dump code, or whether there's also other code needed when Peribolos attempts to apply these permissions.

And also it may be useful to make Peribolos more robust in the event that future team permissions are added by Github, by erroring out if it encounters a permission it does not recognize.

[stevekuznetsov]

/cc @fejta @cjwagner

[adshmh]

This happens because GitHub API calls on ListTeamRepos returns false for all permission levels, i.e. push, pull, admin, when a team has the Maintainer role.

I couldn't find any v3 API calls that returns the beta new roles on a repository, but v4, i.e. graphql endpoint, does seem to report Maintainer or Triage levels

Peribolos does not currently use graphql endpoint, but perhaps it can be updated to do so. This could also mean fewer, ideally a single, calls to get the organisation structure, thus saving tokens.

I'd be happy to submit a patch if this sounds like a good approach.

[stevekuznetsov]

That sounds like it would require a full rewrite of how peribolos works -- I'm not sure that is worth it. @guineveresaenger @nickvanw are there any plans to expose these new fields in v3 API?

[nickvanw]

Hey @stevekuznetsov!

I've passed this feedback on to the PM that owns this part of the product - I agree that it would be great to expose this to the v3 API, and I'll follow up to see if it's on their schedule and, if so, when to expect it.

[stevekuznetsov]

Thanks, @nickvanw! Appreciate your help here :)

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[cblecker]

/remove-lifecycle rotten

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[adshmh]

/remove-lifecycle stale