Merge branch 'main' into action-search-pa11y

Author: chiedo

.github/workflows/60-days-stale-check.yml

@@ -17,4 +17,6 @@ jobs:
         only-labels: 'engineering'
         stale-issue-label: 'stale'
         stale-pr-label: 'stale'
+        exempt-pr-labels: 'never-stale'
+        exempt-issue-labels: 'never-stale'
 

.github/workflows/browser-test.yml

@@ -20,18 +20,22 @@ jobs:
           paths: '[".github/workflows/browser-test.yml","assets/**", "content/**", "data/**", "includes/**", "javascripts/**", "jest-puppeteer.config.js", "jest.config.js", "layouts/**", "lib/**", "middleware/**", "package-lock.json", "package.json", "server.js", "translations/**", "webpack.config.js"]'
   build:
     needs: see_if_should_skip
-    if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
     runs-on: ubuntu-latest
     steps:
-      - name: Checkout
+      # Each of these ifs needs to be repeated at each step to make sure the required check still runs
+      # Even if if doesn't do anything
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Checkout
         uses: actions/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f
 
-      - name: Install
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Install
         uses: ianwalter/puppeteer@12728ddef82390d1ecd4732fb543f62177392fbb
         with:
           args: npm ci
 
-      - name: Test
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Test
         uses: ianwalter/puppeteer@12728ddef82390d1ecd4732fb543f62177392fbb
         with:
           args: npm run browser-test

.github/workflows/test.yml

@@ -31,42 +31,50 @@ jobs:
 
   test:
     needs: see_if_should_skip
-    if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
     runs-on: ubuntu-latest
     timeout-minutes: 60
     strategy:
       fail-fast: false
       matrix:
         test-group: [content, meta, rendering, routing, unit, links-and-images]
     steps:
-      - name: Check out repo
+      # Each of these ifs needs to be repeated at each step to make sure the required check still runs
+      # Even if if doesn't do anything
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Check out repo
         uses: actions/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f
 
-      - name: Setup node
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Setup node
         uses: actions/setup-node@56899e050abffc08c2b3b61f3ec6a79a9dc3223d
         with:
           node-version: 14.x
 
-      - name: Get npm cache directory
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Get npm cache directory
         id: npm-cache
         run: |
           echo "::set-output name=dir::$(npm config get cache)"
 
-      - name: Cache node modules
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Cache node modules
         uses: actions/cache@0781355a23dac32fd3bac414512f4b903437991a
         with:
           path: ${{ steps.npm-cache.outputs.dir }}
           key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
           restore-keys: |
             ${{ runner.os }}-node-
 
-      - name: Install dependencies
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Install dependencies
         run: npm ci
 
-      - name: Run build script
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Run build script
         run: npm run build
 
-      - name: Run tests
+      - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
+        name: Run tests
         run: npx jest tests/${{ matrix.test-group }}/
         env:
           NODE_OPTIONS: "--max_old_space_size=4096"

.github/workflows/triage-stale-check.yml

@@ -16,3 +16,5 @@ jobs:
         days-before-stale: 7
         days-before-close: 10
         stale-pr-label: 'stale'
+        exempt-pr-labels: 'never-stale'
+        exempt-issue-labels: 'never-stale'

CONTRIBUTING.md

@@ -114,7 +114,8 @@ You can browse existing issues to find something that needs help!
 
 ### Labels
 Labels can help you find an issue you'd like to help with.
-- The [`good-first-issue` label](https://github.com/github/docs/issues?q=is%3Aopen+is%3Aissue+label%3Agood-first-issue) is for problems or updates we think are ideal for beginners.
+- The [`help wanted` label](https://github.com/github/docs/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) is for problems or updates that anyone in the community can start working on.
+- The [`good first issue` label](https://github.com/github/docs/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) is for problems or updates we think are ideal for beginners.
 - The [`content` label](https://github.com/github/docs/issues?q=is%3Aopen+is%3Aissue+label%3Acontent) is for problems or updates in the content on docs.github.com. These will usually require some knowledge of Markdown.
 - The [`engineering` label](https://github.com/github/docs/issues?q=is%3Aopen+is%3Aissue+label%3Aengineering) is for problems or updates in the docs.github.com website. These will usually require some knowledge of JavaScript/Node.js or YAML to fix.
 

content/actions/learn-github-actions/introduction-to-github-actions.md

@@ -42,15 +42,15 @@ A job is a set of steps that execute on the same runner. By default, a workflow
 
 #### Steps
 
-A step is an individual task that can run commands (known as _actions_). Each step in a job executes on the same runner, allowing the actions in that job to share data with each other.
+A step is an individual task that can run commands in a job. A step can be either an _action_ or a shell command. Each step in a job executes on the same runner, allowing the actions in that job to share data with each other.
 
 #### Actions
 
 _Actions_ are standalone commands that are combined into _steps_ to create a _job_. Actions are the smallest portable building block of a workflow. You can create your own actions, or use actions created by the {% data variables.product.prodname_dotcom %} community. To use an action in a workflow, you must include it as a step.
 
 #### Runners
 
-A runner is a server that has the {% data variables.product.prodname_actions %} runner application installed. You can use a runner hosted by {% data variables.product.prodname_dotcom %}, or you can host your own. A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to {% data variables.product.prodname_dotcom %}. For {% data variables.product.prodname_dotcom %}-hosted runners, each job in a workflow runs in a fresh virtual environment.
+A runner is a server that has the [{% data variables.product.prodname_actions %} runner application](https://github.com/actions/runner) installed. You can use a runner hosted by {% data variables.product.prodname_dotcom %}, or you can host your own. A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to {% data variables.product.prodname_dotcom %}. For {% data variables.product.prodname_dotcom %}-hosted runners, each job in a workflow runs in a fresh virtual environment.
 
 {% data variables.product.prodname_dotcom %}-hosted runners are based on Ubuntu Linux, Microsoft Windows, and macOS. For information on {% data variables.product.prodname_dotcom %}-hosted runners, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/virtual-environments-for-github-hosted-runners)." If you need a different operating system or require a specific hardware configuration, you can host your own runners. For information on self-hosted runners, see "[Hosting your own runners](/actions/hosting-your-own-runners)."
 
@@ -197,7 +197,7 @@ To help you understand how YAML syntax is used to create a workflow file, this s
 
 #### Visualizing the workflow file
 
-In this diagram, you can see the workflow file you just created and how the {% data variables.product.prodname_actions %} components are organized in a hierarchy. Each step executes a single action. Steps 1 and 2 use prebuilt community actions. To find more prebuilt actions for your workflows, see "[Finding and customizing actions](/actions/learn-github-actions/finding-and-customizing-actions)."
+In this diagram, you can see the workflow file you just created and how the {% data variables.product.prodname_actions %} components are organized in a hierarchy. Each step executes a single action or shell command. Steps 1 and 2 use prebuilt community actions. Steps 3 and 4 run shell commands directly on the runner. To find more prebuilt actions for your workflows, see "[Finding and customizing actions](/actions/learn-github-actions/finding-and-customizing-actions)."
 
 ![Workflow overview](/assets/images/help/images/overview-actions-event.png)
 

content/actions/reference/events-that-trigger-workflows.md

@@ -327,6 +327,7 @@ The `issue_comment` event occurs for comments on both issues and pull requests.
 
 For example, you can choose to run the `pr_commented` job when comment events occur in a pull request, and the `issue_commented` job when comment events occur in an issue.
 
+{% raw %}
 ```yaml
 on: issue_comment
 
@@ -349,6 +350,7 @@ jobs:
       - run: |
           echo "Comment on issue #${{ github.event.issue.number }}"
 ```
+{% endraw %}
 
 #### `issues`
 

content/actions/reference/workflow-syntax-for-github-actions.md

@@ -446,7 +446,7 @@ steps:
     uses: monacorp/action-name@main
   - name: My backup step
     if: {% raw %}${{ failure() }}{% endraw %}
-    uses: actions/heroku@master
+    uses: actions/heroku@1.0.0
 ```
 
 #### **`jobs.<job_id>.steps.name`**
@@ -492,7 +492,7 @@ jobs:
     steps:
       - name: My first step
         # Uses the default branch of a public repository
-        uses: actions/heroku@master
+        uses: actions/heroku@1.0.0
       - name: My second step
         # Uses a specific version tag of a public repository
         uses: actions/aws@v2.0.1
@@ -659,7 +659,7 @@ For built-in shell keywords, we provide the following defaults that are executed
 
 - `cmd`
   - There doesn't seem to be a way to fully opt into fail-fast behavior other than writing your script to check each error code and respond accordingly. Because we can't actually provide that behavior by default, you need to write this behavior into your script.
-  - `cmd.exe` will exit with the error level of the last program it executed, and it will and return the error code to the runner. This behavior is internally consistent with the previous `sh` and `pwsh` default behavior and is the `cmd.exe` default, so this behavior remains intact.
+  - `cmd.exe` will exit with the error level of the last program it executed, and it will return the error code to the runner. This behavior is internally consistent with the previous `sh` and `pwsh` default behavior and is the `cmd.exe` default, so this behavior remains intact.
 
 #### **`jobs.<job_id>.steps.with`**
 
@@ -718,7 +718,7 @@ steps:
       entrypoint: /a/different/executable
 ```
 
-The `entrypoint` keyword is meant to use with Docker container actions, but you can also use it with JavaScript actions that don't define any inputs.
+The `entrypoint` keyword is meant to be used with Docker container actions, but you can also use it with JavaScript actions that don't define any inputs.
 
 #### **`jobs.<job_id>.steps.env`**
 

content/developers/overview/secret-scanning.md

@@ -79,7 +79,7 @@ Content-Length: 0123
 ]
 ```
 
-The message body is a JSON array that contains one or more objects with the following contents. When multiple matches are found, {% data variables.product.prodname_dotcom %}  may send a single message with more than one secret match.
+The message body is a JSON array that contains one or more objects with the following contents. When multiple matches are found, {% data variables.product.prodname_dotcom %}  may send a single message with more than one secret match. Your endpoint should be able to handle requests with a large number of matches without timing out.
 
 * **Token**: The value of the secret match.
 * **Type**: The unique name you provided to identify your regular expression.
@@ -139,7 +139,7 @@ func main() {
     fmt.Printf("Error preparing request: %s\n", err)
     os.Exit(1)
   }
-  
+
   if len(os.Getenv("GITHUB_PRODUCTION_TOKEN")) == 0 {
     fmt.Println("Need to define environment variable GITHUB_PRODUCTION_TOKEN")
     os.Exit(1)

content/github/finding-security-vulnerabilities-and-errors-in-your-code/troubleshooting-the-codeql-workflow.md

@@ -66,7 +66,7 @@ For more information, see the workflow extract in "[Automatic build for a compil
    * Building using a distributed build system external to GitHub Actions, using a daemon process.
    * {% data variables.product.prodname_codeql %} isn't aware of the specific compiler you are using.
 
-  For C# projects using either `dotnet build` or `msbuild` which target .NET Core 2, you should specify `/p:UseSharedCompilation=false` in your workflow's `run` step, when you build your code. The `UseSharedCompilation` flag isn't necessary for .NET Core 3.0 and later.
+  For .NET Framework projects, and for C# projects using either `dotnet build` or `msbuild` that target .NET Core 2, you should specify `/p:UseSharedCompilation=false` in your workflow's `run` step, when you build your code. The `UseSharedCompilation` flag isn't necessary for .NET Core 3.0 and later.
 
   For example, the following configuration for C# will pass the flag during the first build step.