-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define github-hostname for trusted teams #1069
Conversation
Useful for scenarios where trusted-teams from multiple github instances have to be considered. Co-authored-by: Tuan Anh Nguyen <[email protected]>
/hold do not merge (yet), requires cfg changes |
@dataclasses.dataclass(frozen=True) | ||
class TrustedTeams: | ||
github_hostname: str | ||
teams: list[str] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
list is mutable. declaring the dataclass as frozen is inconsistent w/ that. suggestion: declare the class as mutable (non-frozen)
'''Pull requests created/synchronized by members of this team will automatically have | ||
the required label set by the webhook-dispatcher | ||
''' | ||
return self.raw.get('trusted_teams', []) | ||
return [ | ||
dacite.from_dict( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we keep this simpler and just keep a list of strings? it should be fairly simple to discriminate between qualified and non-qualified teams, as github does not allow /
(or .
for that matter) characters in team-names.
Hence, entries of the form foo/bar
(two parts if splitting by /
) should be safe to translate to <org>/<teamname>
, whereas entries of the form host.tld/foo/bar
(three parts if splitting by /
) should be safe to interpret as qualified
merge with #1070 , let's follow-up there |
Useful for scenarios where trusted-teams from multiple github instances have to be considered.
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note: