Description
can_merge_pr(username) checks if a user has admin or write permission on a GitHub repository. packit-service uses this to decide who can trigger commands like /packit test on PRs, but "can merge" is not the right question for "can interact with the bot".
GitHub's "triage" role grants permissions that are conceptually sufficient for triggering CI (close/reopen issues and PRs, request reviews, manage labels) without granting write access to repository contents.
Benefit
This would allow project maintainers to give collaborators the triage role instead of write, letting them trigger /packit test and similar commands without granting unnecessarily broad repository access.
Importance
Today, the only way to let someone trigger packit commands is to give them write access, which violates least-privilege. There is no way to distinguish "can trigger CI" from "can push code" in the permission model.
Proposal:
Add a method that checks against a broader set of permissions. Either a targeted one:
def can_trigger_ci(self, username: str) -> bool:
# accepts {"admin", "write", "maintain", "triage"}or a more general one using GitHub's permission hierarchy (read < triage < write < maintain < admin):
def has_at_least_permission(self, username: str, level: str) -> bool:
This would let consumers like packit-service use the appropriate check for the action being authorized.
Workaround
Participation
Description
can_merge_pr(username)checks if a user hasadminorwritepermission on a GitHub repository.packit-serviceuses this to decide who can trigger commands like/packit teston PRs, but"can merge"is not the right question for"can interact with the bot".GitHub's
"triage"role grants permissions that are conceptually sufficient for triggering CI (close/reopen issues and PRs, request reviews, manage labels) without granting write access to repository contents.Benefit
This would allow project maintainers to give collaborators the
triagerole instead ofwrite, letting them trigger/packit testand similar commands without granting unnecessarily broad repository access.Importance
Today, the only way to let someone trigger packit commands is to give them
writeaccess, which violates least-privilege. There is no way to distinguish"can trigger CI"from"can push code"in the permission model.Proposal:
Add a method that checks against a broader set of permissions. Either a targeted one:
or a more general one using GitHub's permission hierarchy (
read<triage<write<maintain<admin):This would let consumers like
packit-serviceuse the appropriate check for the action being authorized.Workaround
Participation