Since the edk2 repository is owned by an organization, the default
GitHub token will not be able to access the collaborator list.
Therefore, a GitHub App with `metadata:read` permission will be used
to grant access to that REST API. This is used in GitHub.py when it
makes the `repo_gh.get_collaborators()` call that resolves to the
`/repos/{owner}/{repo}/collaborators` GitHub REST API.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
To make the Python code used within the action more mantainable over
time, it is moved to a standalone script in .github/scripts.
No functional changes are made to the workflow itself.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds additional documentation and cleans up debug messages printed
to GitHub workflow output (available in the GitHub Actions pane).
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Updates logic to:
- Not request reviews from reviewers that have already left a review
on the PR. Previously, the reviewers review (e.g. approval) would
remain on the PR, but they would be notified on each change to the
PR. This approach follows the expected notification process for
requesting reviews which is one time. Maintainers and reviewers can
set up their own notifications for more granular updates on PR
activity separately.
- Add the collaborator reviewers if a reviewer(s) is found to not be
a collaborator. This is an improvement to today's behavior which is
to not add any reviewers if a single reviewer is not a collaborator
of the repo.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Uses PyGithub for GitHub interactions instead of the GitHub REST API
directly.
This simplifies the code, improves error handling and robustness, and
lets the PyGithub project abstract GitHub REST API changes that may
occur over time.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Uses `GitPython` instead of invoking the git executable directly.
This has the benefit of improving code readability and less support
code for binary interaction.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
- Optimizes and makes the PIP module installation process for the
workflow more robust by caching the pip modules used so the only
time the workflow needs to reach to PyPi is when new PIP modules
are published.
- Improves long term stability by locking the major versions for PIP
modules in the workflow. This is to reduce overall maintenance over
time to automatically pick up new versions while also not being
broken in the process.
- Removes edk2-pytool-extensions as it is not used.
The new "requirements.txt" file is used to lock versions and support
the caching step which depends on a requirements file.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Optimizes the repository checkout step from an average time of 21
to 1 second by performing a sparse checkout of only the file paths
needed for the workflow run at a fetch depth of 1.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
This change simply moves the trigger to `pull_request_target`. The
rest of this message contains verbose details related to that.
`pull_request_target` is used instead of `pull_request` since the
default GitHub token cannot pick up write permissions with the
`pull_request` type on PRs from public forks. Write permission is
needed to add reviewrs. This was previously tested on an edk2 fork
where PRs were not from other public forks into the fork being used
for testing but directly on the fork itself.
Because `pull_request_target` runs the pull request in the context
of the base branch (not the PR branch) some logic needs slightly
modified. The main change is that the GitHub context will no longer
give the PR branch HEAD as the PR commit SHA (i.e.
`github.event.pull_request.head.sha`). The SHA will be the base
branch (`master`) SHA as that is what is checked out for the
workflow run. SO, the actual PR SHA is now fetched separately.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds a new GitHub workflow to automatically add reviewers to pull
requests when they are opened, reopened, synchronized, and if a draft
pull request is marked as ready for review. The workflow will not
run on draft pull requests.
The workflow is meant to be simple to understand and modify, relying
on existing logic in GetMaintainer.py to determine the relevant
reviewers and using simple Python GitHub REST API wrappers with the
default GitHub token for authentication.
Future changes may optimize the workflow.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Michael Kubacki