Enable automatic labeling of PRs via Actions (#3431)

* Automatically label PRs based on the file paths

Signed-off-by: Nolan Brubaker <brubakern@vmware.com>

* Enable prow-like commands

Signed-off-by: Nolan Brubaker <brubakern@vmware.com>

* Require filling in the PR template

Signed-off-by: Nolan Brubaker <brubakern@vmware.com>

* Update contributor docs to reference PR template

Signed-off-by: Nolan Brubaker <brubakern@vmware.com>

* Expand checklist and ask for issue number on PRs

Signed-off-by: Nolan Brubaker <brubakern@vmware.com>

* Document why we're not enabling /lgtm yet

Signed-off-by: Nolan Brubaker <brubakern@vmware.com>

* Combine PR assignment and labeling workflow

Signed-off-by: Nolan Brubaker <brubakern@vmware.com>

.github/PULL_REQUEST_TEMPLATE/pr.md

@@ -0,0 +1,13 @@
+Thank you for contributing to Velero!
+
+# Please add a summary of your change
+
+# Does your change fix a particular issue?
+
+Fixes #(issue)
+
+# Please indicate you've done the following:
+
+[ ] [Accepted the DCO](https://velero.io/docs/v1.5/code-standards/#dco-sign-off). Commits without the DCO will delay acceptance.
+[ ] [Created a changelog file](https://velero.io/docs/v1.5/code-standards/#adding-a-changelog) or added `/kind changelog-not-required`.
+[ ] Updated the corresponding documentation in `site/content/docs/main`.

.github/labels.yml

@@ -0,0 +1,40 @@
+area:
+  - "Cloud/AWS"
+  - "Cloud/GCP"
+  - "Cloud/Azure"
+  - "Plugins"
+
+# Labels that can be applied to PRs with the /kind command
+kind:
+  - "changelog-not-required"
+  - "Tech debt"
+
+# Works with https://github.com/actions/labeler/
+# Below this line, the keys are labels to be applied, and the values are the file globs to match against.
+# Anything in the `design` directory gets the `Design` label.
+Design:
+  - design/*
+
+# Anything in the site directory gets the website label *EXCEPT* docs
+Website:
+  - any: ["site/**/*", "!site/content/docs/**/*"]
+
+Documentation:
+  - site/content/docs/**/*
+
+Dependencies:
+  - go.mod
+
+# Anything that has plugin infra will be labeled.
+# Individual plugins don't necessarily live here, though
+Plugins:
+  - "pkg/plugins/**/*"
+
+has-unit-tests:
+  - "pkg/**/*_test.go"
+
+has-e2e-2tests:
+  - "test/e2e/**/*"
+
+has-changelog:
+  - "changelogs/**"

.github/workflows/auto_assign_prs.yml

@@ -1,16 +1,24 @@
-name: 'Auto Assign PR Reviewers'
+name: "Auto Assign PR Reviewers"
 # pull_request_target means that this will run on pull requests, but in the context of the base repo.
 # This should mean PRs from forks are supported.
 on:
   pull_request_target:
     types: [opened, reopened, synchronize, ready_for_review]
 
-
 jobs:
+  # Automatically assigns reviewers and owner
   add-reviews:
     runs-on: ubuntu-latest
     steps:
       - uses: kentaro-m/auto-assign-action@v1.1.1
         with:
           configuration-path: ".github/auto_assign.yml"
-          repo-token: '${{ secrets.GITHUB_TOKEN }}'
+          repo-token: "${{ secrets.GITHUB_TOKEN }}"
+  # Automatically labels PRs based on file globs in the change.
+  triage:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/labeler@main
+        with:
+          repo-token: "${{ secrets.GITHUB_TOKEN }}"
+          configuration-path: .github/labels.yaml

.github/workflows/prow-action.yml

@@ -0,0 +1,20 @@
+# Adds support for prow-like commands
+# Uses .github/labels.yaml to define areas and kinds
+name: "Prow github actions"
+on:
+  issue_comment:
+    types: [created]
+
+jobs:
+  execute:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: jpmcb/prow-github-actions@v1
+        with:
+          # Only support /kind command for now.
+          # TODO: before allowing the /lgtm command, see if we can block merging if changelog labels are missing.
+          prow-commands: "/area
+            /kind
+            /cc
+            /uncc"
+          github-token: "${{ secrets.GITHUB_TOKEN }}"

site/content/docs/main/code-standards.md

@@ -6,17 +6,7 @@ toc: "true"
 
 ## Opening PRs
 
-Some PRs do not require a CI build. Those will be changes to documentation, to the website, and any other change that doesn't involve code, such as releases, typo fixes.
-
-To bypass the CI build, use anyone of these labels (any one of them will do the job):
-- Design: any design document
-- Website: any change to the website that is not documentation
-- Documentation: documentation for releases or any markdown file in the repo 
-- changelog-not-required: use only when the PR is not addressing any of the above cases. This is for changes in the code that is not introducing any change in behavior for the software. 
-
-There is no need to use more than one label.
-
-Please add the label BEFORE creating the PR/draft. This will make the CI check pass. If you forget, it's ok: adding it after will make the CI fail, but it will still let us merge. The only minor downside is that it will have a red checkmark for failure.
+When opening a pull request, please fill out the checklist supplied the template. This will help others properly categorize and review your pull request.
 
 ## Adding a changelog
 

site/content/docs/v1.5/code-standards.md

@@ -6,17 +6,7 @@ toc: "true"
 
 ## Opening PRs
 
-Some PRs do not require a CI build. Those will be changes to documentation, to the website, and any other change that doesn't involve code, such as releases, typo fixes.
-
-To bypass the CI build, use anyone of these labels (any one of them will do the job):
-- Design: any design document
-- Website: any change to the website that is not documentation
-- Documentation: documentation for releases or any markdown file in the repo 
-- changelog-not-required: use only when the PR is not addressing any of the above cases. This is for changes in the code that is not introducing any change in behavior for the software. 
-
-There is no need to use more than one label.
-
-Please add the label BEFORE creating the PR/draft. This will make the CI check pass. If you forget, it's ok: adding it after will make the CI fail, but it will still let us merge. The only minor downside is that it will have a red checkmark for failure.
+When opening a pull request, please fill out the checklist supplied the template. This will help others properly categorize and review your pull request.
 
 ## Adding a changelog