Closed Bug 1416057 Opened 7 years ago Closed 6 years ago

Review policy for granting scopes to repositories

Categories

(Taskcluster :: Operations and Service Requests, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1415868

People

(Reporter: jonasfj, Unassigned)

Details

Right now we have a policy that if you can do something through a push you can do it directly using scopes assigned.

We probably need to review this policy, and recognized that there are 3 kinds of users:
 A) Administrators (people who administrate a source code repository)
 B) Repositories   (decision tasks created from a push to a repository)
 C) Contributors   (people who are contributors to a repository)

(A) needs ability to grant scopes to (B) and (C)
(B) is more privileged than (C) in some cases, as pushes have been reviewed before landing.
(C) needs scopes for debugging decision tasks.

In github terms:
 (A) <=> repo owners
 (B) <=> repo decision task, on non-PRs
 (C) <=> people who can open PRs (maybe with some trust concept)

In gecko terms:
 (A) <=> taskcluster team / releng / ateam / build-team
 (B) <=> level-2 / level-3 repositories
 (C) <=> level-1 repositories, try users

Today we're largely lumping (B) and (C) together on gecko.
And on github we don't really have a concept of (A).

We should re-think if we can come up with some sane patterns for this.
So we can assign scopes to repo owners and have them manage what scopes
branches have.

This also means re-thinking the concept that anything you can do in a push can be done with your credentials. This might still be true for try, but probably not for level-3 users, as such pushes are required to be reviewed and we have systems for monitoring the pushes.
Found in triage.

We should have this documented somewhere.
This is happening for gecko as part of actions-as-hooks (bug 1415868).  I plan to include some in-tree docs there, too (and more so when the roles are defined in-tree).  We're very far from having a story about github repo ownership, and need to deal with github logins in that process too.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Component: Operations → Operations and Service Requests
You need to log in before you can comment on or make changes to this bug.