Skip to content

Latest commit

 

History

History
250 lines (195 loc) · 10.8 KB

33-automate-pr-assignees.md

File metadata and controls

250 lines (195 loc) · 10.8 KB
Raw

enhancement-33: Automate assignees on enhancement proposal PRs

Release Signoff Checklist

  • Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
  • Core members have approved the issue with the label implementable
  • Design details are appropriately documented
  • Test plan is in place
  • User-facing documentation has been created in [keylime/keylime-docs]

Summary

Keylime's enhancements process uses Github's Pull Requests feature for proposing changes, allowing collaborators to make use of the robust review tools to suggest improvements or facilitate discussion. The process does not, however, make use of Github's assignee or review request features. This presents an opportunity to apply some generalized automation work done for the Enarx project around making PR assignees more useful than a manual field -- instead, automating it to directly indicate who is responsible for pushing a PR towards merge. This work could also eventually apply to other Keylime repos as well.

Motivation

Github's PR assignee feature is currently underutilized. At best, it's usually used to designate someone as a point of contact for that PR.

The Enarx project has developed some automation tools that seek to change that, however -- in particular, making a PR's current assignee reflect immediate responsibility for pushing a PR forward. Effectively, whenever something is assigned to someone, that assignment means they, specifically, are needed -- a nice usability benefit for developers and reviewers.

Goals

Enable automation from Enarx on keylime/enhancements

Non-Goals

TBD

Proposal

The proposed automation was developed and refined for the Enarx project and available through enarx/bot, or the Enarxbot. The particular component of interest for this proposal has been split out and made generally available in actions-automation/pr-workflow, which contains a standalone Github Action with relevant logic.

Once this action has been included (using a workflow .yml present in .github/workflows) and other requisite setup steps taken, the bot should:

  • Automatically request a specified number of reviewers on new pull requests -- in addition to code owners (requested by Github), the bot will request a suggested reviewer, in addition to however many people are needed to hit a user-input target number of reviewers from a user-defined Github team;
  • Automatically change PR assignees based on the current state of the PR and its reviews.

Here's an example of a typical timeline of events on a PR:

  • Alice opens a PR. Bob, Charlie, and Dora are requested for review.
  • Bob, Charlie, and Dora are assigned to the PR, and Alice is not (since she is still awaiting a review, she can't do anything else to push it forward).
  • Bob submits a review requesting changes. Bob is unassigned from the PR, and Alice is reassigned, since she must address Bob's review.
  • Alice submits a patch to the PR addressing Bob's changes, and requests a re-review. Alice is once again unassigned from the PR, while Bob is reassigned.
  • Bob thinks the changes look good, and approves the PR. Bob is unassigned, since he's approved it.
  • Alice pushes another patch, dismissing Bob's approving review. Bob is assigned again to approve the updated PR.

This cycle repeats until a satisfactory number of approvals has been reached and there are no outstanding Changes Requested reviews.

This cycle is excellent for indicating responsibility, and, on the Enarx project, has been positively received.

User Stories (optional)

Story 1

Story 2

Notes/Constraints/Caveats (optional)

Risks and Mitigations

TBD

Design Details

TBD

Test Plan

TBD

Upgrade / Downgrade Strategy

Removing the appropriate Actions workflow should disable automation cleanly.

Drawbacks

TBD

Alternatives

No direct alternatives.

Infrastructure Needed (optional)

In order to fully do its magic, the bot needs several things:

  • A separate user account, scoped to have write access to the Keylime organization (in this case, write access to repos it interacts with should be enough)
  • a personal access token with the public_repo scope stored as a shared organization secret, named BOT_TOKEN.
  • a Github Team in the parent organization that contains people that may be requested to review pull requests
  • (optional) a set of code owners specified in a CODEOWNERS file