FAQs¶
Why is this GitHub application necessary?¶
This application is necessary to ensure that pull requests from public repository forks are properly vetted before any CI workflows run on them.
Running workflows on pull requests from public forks without vetting them first is a security risk. This becomes especially important for CI machines that are self-hosted.
For additional details about the motivation behind this application, view the onboarding page here.
What are my responsibilities as a vetter?¶
Vetters are responsible for ensuring that the changes introduced by a pull request are both legitimate and benign.
If a commit introduces changes that seem suspicious (running network scans, uploading/downloading/executing suspicious files, trying to access secrets, etc.), reach out to an organization or repository administrator for additional guidance.
If the changes are legitimate and benign, an /ok to test
comment can be left on the pull request to copy its code to a branch in the source repository so that a CI workflow can begin.
Every subsequent commit on an untrusted pull request will also need to be vetted and will require an additional /ok to test
comment.
Why did I receive a comment that my pull request requires additional validation?¶
Note
For definitions of the bolded terms below, view the glossary.
If any of the criteria below are true, a pull request is deemed untrusted and will require an /ok to test
comment from a vetter for every subsequent commit that is pushed:
- The pull request was opened by an untrusted user
- The pull request contains commits from an unknown or untrusted user
- The pull request contains 250 commits or greater
- The pull request contains unsigned commits (see this GitHub documentation about signing commits)
In the event that a trusted user accidentally pushes an unsigned commit, they may rebase their changes locally to sign the commit(s) in question and force push an update to their pull request. Assuming all of the rebased changes are trusted changes, the pull request will no longer require an /ok to test
comment.
Why didn't my /ok to test
comment work?¶
If an /ok to test
comment didn't work as expected, check the following items:
- Ensure that the author of the
/ok to test
comment is a vetter as defined in the glossary - Ensure that the
/ok to test
comment matches this regular expression:^/ok(ay)? to test$
. Whitespace is trimmed.
A successful /ok to test
comment will receive a 👍 reaction from copy-pr-bot
.
How can I obtain pull request information from the on: push
workflow?¶
The nv-gha-runners/get-pr-info shared action can be used to obtain additional pull request information (e.g. the base branch) from an on: push
triggered workflow.
The application isn't working correctly. How can I troubleshoot?¶
Here are a few things to check if the application isn't working as expected:
- Ensure the application is installed on the repository in question. An organization or repository administrator will typically have to verify this.
- Ensure the
copy-pr-bot.yaml
file is committed to the default branch. The application won't start working until the file is on the default branch of the repository. - Ensure the
copy-pr-bot.yaml
file has the correct file name and is in the correct directory. It should be in.github/copy-pr-bot.yaml
exactly. Using a.yml
file extension will not work.
Can I ignore pull-request/*
branches locally?¶
Yes, you can avoid fetching pull-request/*
branches locally by running the git
command below, where upstream
in remote.upstream.fetch
is the git
remote name corresponding to the source repository:
git config \
--global \
--add "remote.upstream.fetch" \
'^refs/heads/pull-request/*'
Note that this git
configuration option requires git
version 2.29
or greater to support negative refspecs (source).
Will the application clean up branches that it creates?¶
Yes. Anytime a pull request is closed or merged, it's corresponding branch in the source repository is also deleted.