Merge branch 'main' into patch-1

.github/CODEOWNERS

@@ -21,8 +21,8 @@ package.json @github/docs-engineering
 /content/github/site-policy/ @github/site-policy-admins
 
 # Content strategy
-/contributing/content-markup-reference.md @github/product-docs-content-strategy
+/contributing/content-markup-reference.md @github/docs-content-strategy
-/contributing/content-style-guide.md @github/product-docs-content-strategy
+/contributing/content-style-guide.md @github/docs-content-strategy
 
 # Make sure that Octokit maintainers get notified about changes
 # relevant to the Octokit libraries (https://github.com/octokit)

.github/PULL_REQUEST_TEMPLATE.md

@@ -21,7 +21,6 @@ Thanks again!
 <!-- Share artifacts of the changes, be they code snippets, GIFs or screenshots; whatever shares the most context. -->
 
 ### Check off the following:
-- [ ] All of the tests are passing.
 - [ ] I have reviewed my changes in staging. (look for the **deploy-to-heroku** link in your pull request, then click **View deployment**)
 - [ ] For content changes, I have reviewed the [localization checklist](https://github.com/github/docs/blob/main/contributing/localization-checklist.md)
 - [ ] For content changes, I have reviewed the [Content style guide for GitHub Docs](https://github.com/github/docs/blob/main/contributing/content-style-guide.md).

.github/allowed-actions.js

@@ -25,12 +25,13 @@ module.exports = [
   'pascalgn/automerge-action@c9bd182',
   'peter-evans/create-issue-from-file@a04ce672e3acedb1f8e416b46716ddfd09905326',
   'peter-evans/create-or-update-comment@5221bf4aa615e5c6e95bb142f9673a9c791be2cd',
-  'peter-evans/create-pull-request@938e6aea6f8dbdaced2064e948cb806c77fe87b8',
+  'peter-evans/create-pull-request@8c603dbb04b917a9fc2dd991dc54fef54b640b43',
   'rachmari/actions-add-new-issue-to-column@1a459ef92308ba7c9c9dc2fcdd72f232495574a9',
   'rachmari/labeler@832d42ec5523f3c6d46e8168de71cd54363e3e2e',
   'repo-sync/github-sync@3832fe8e2be32372e1b3970bbae8e7079edeec88',
   'repo-sync/pull-request@33777245b1aace1a58c87a29c90321aa7a74bd7d',
   'someimportantcompany/github-actions-slack-message@0b470c14b39da4260ed9e3f9a4f1298a74ccdefd',
   'tjenkinson/gh-action-auto-merge-dependency-updates@cee2ac0',
-  'EndBug/add-and-commit@9358097a71ad9fb9e2f9624c6098c89193d83575'
+  'EndBug/add-and-commit@9358097a71ad9fb9e2f9624c6098c89193d83575',
+  'dorny/paths-filter@eb75a1edc117d3756a18ef89958ee59f9500ba58'
 ]

.github/workflows/autoupdate-repo-sync-branch-on-cron.yml

@@ -1,15 +0,0 @@
-name: autoupdate reposync branch on cron
-on:
-  schedule:
-    - cron: '*/5 * * * *'
-jobs:
-  autoupdate:
-    name: autoupdate
-    runs-on: ubuntu-18.04
-    steps:
-      - uses: docker://chinthakagodawita/autoupdate-action:v1
-        env:
-          GITHUB_TOKEN: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}
-          PR_FILTER: labelled
-          PR_LABELS: 'automated-reposync-pr'
-          MERGE_MSG: "Branch was updated using the 'autoupdate reposync branch on cron' Actions workflow."

.github/workflows/close-unwanted-pull-requests.yml

@@ -1,39 +0,0 @@
-name: Close unwanted pull requests
-on:
-  pull_request:
-    paths:
-      - '.github/workflows/**'
-      - '.github/CODEOWNERS'
-      - 'translations/**'
-      - 'assets/fonts/**'
-      - 'data/graphql/**'
-      - 'lib/graphql/**'
-      - 'lib/redirects/**'
-      - 'lib/webhooks/**'
-jobs:
-  close_unwanted_pull_requests:
-    if: github.repository == 'github/docs' && github.event.pull_request.user.login != 'Octomerger'
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
-        with:
-          script: |
-            await github.issues.createComment({
-              ...context.repo,
-              issue_number: context.payload.pull_request.number,
-              body:
-            `Thanks for contributing! We do not accept community changes to these files at this time.
-            - '.github/workflows/**'
-            - '.github/CODEOWNERS'
-            - 'translations/**'
-            - 'assets/fonts/**'
-            - 'data/graphql/**'
-            - 'lib/graphql/**'
-            - 'lib/redirects/**'
-            - 'lib/webhooks/**'`
-            })
-            await github.issues.update({
-              ...context.repo,
-              issue_number: context.payload.pull_request.number,
-              state: 'closed'
-            })

.github/workflows/codeql.yml

@@ -2,6 +2,9 @@ name: CodeQL analysis
 
 on:
   push:
+    branches: main
+  pull_request:
+    branches: main
     paths:
       - '**/*.js'
       - '.github/workflows/codeql.yml'

.github/workflows/confirm-internal-staff-work-in-docs.yml

@@ -17,7 +17,8 @@ jobs:
     continue-on-error: true
     if: github.repository == 'github/docs'
     steps:
-      - uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+      - id: membership_check
+        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
         with:
           github-token: ${{ secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES }}
           script: |
@@ -61,10 +62,10 @@ jobs:
               body: `@${context.payload.sender.login} opened https://github.com/github/docs/issues/${issueNo} publicly in the github/docs repo, instead of the private github/docs-internal repo.\n\n@${context.payload.sender.login}, please confirm that this belongs in the public repo and that no sensitive information was disclosed by commenting below and closing the issue.\n\nIf this was not intentional and sensitive information was shared, please delete https://github.com/github/docs/issues/${issueNo} and notify us in the \#docs-open-source channel.\n\nThanks! \n\n/cc @github/docs @github/docs-engineering`
             });
 
-            throw new Error('A Hubber opened an issue on the public github/docs repo');
+            core.setOutput('did_warn', 'true')
 
       - name: Send Slack notification if a GitHub employee who isn't on the docs team opens an issue in public
-        if: ${{ failure() && github.repository == 'github/docs' }}
+        if: ${{ steps.membership_check.outputs.did_warn && github.repository == 'github/docs' }}
         uses: someimportantcompany/github-actions-slack-message@0b470c14b39da4260ed9e3f9a4f1298a74ccdefd
         with:
           channel: ${{ secrets.DOCS_OPEN_SOURCE_SLACK_CHANNEL_ID }}

.github/workflows/remove-unused-assets.yml

@@ -33,7 +33,7 @@ jobs:
       - name: Remove script results file
         run: rm -rf ./results.md
       - name: Create pull request
-        uses: peter-evans/create-pull-request@938e6aea6f8dbdaced2064e948cb806c77fe87b8
+        uses: peter-evans/create-pull-request@8c603dbb04b917a9fc2dd991dc54fef54b640b43
         with:
           # need to use a token with repo and workflow scopes for this step
           token: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}

.github/workflows/repo-sync-stalls.yml

@@ -36,11 +36,18 @@ jobs:
               return
             }
 
+            // Remove all pull requests that don't have the 
+            // 'automated-reposync-pr' label
+            pulls.data = pulls.data.filter(pr =>
+              pr.labels.some(label => label.name === 'automated-reposync-pr')
+            )
+
+            // Search for pull requests that have been open too long
             pulls.data.forEach(pr => {
               const timeDelta = Date.now() - Date.parse(pr.created_at);
               const minutesOpen = timeDelta / 1000 / 60;
 
-              if (minutesOpen > 30) {
+              if (minutesOpen > 180) {
                 core.setFailed('Repo sync appears to be stalled') 
               }
             })

.github/workflows/repo-sync.yml

@@ -44,6 +44,7 @@ jobs:
           github_token: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}
 
       - name: Create pull request
+        id: create-pull
         uses: repo-sync/pull-request@33777245b1aace1a58c87a29c90321aa7a74bd7d
         env:
           GITHUB_TOKEN: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}
@@ -70,6 +71,35 @@ jobs:
           github-token: ${{ secrets.GITHUB_TOKEN }}
           number: ${{ steps.find-pull-request.outputs.number }}
 
+      # There are cases where the branch becomes out-of-date in between the time this workflow began and when the pull request is created/updated
+      - name: Update branch
+        if: ${{ steps.find-pull-request.outputs.number }}
+        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const mainHeadSha = await github.git.getRef({
+              ...context.repo,
+              ref: 'heads/main'
+            })
+            console.log(`heads/main sha: ${mainHeadSha.data.object.sha}`)
+
+            const pull = await github.pulls.get({
+              ...context.repo,
+              pull_number: parseInt(${{ steps.find-pull-request.outputs.number }})
+            })
+            console.log(`Pull request base sha: ${pull.data.base.sha}`)
+
+            if (mainHeadSha.data.object.sha !== pull.data.base.sha || pull.data.mergeable_state === 'behind') {
+              const updateBranch = await github.pulls.updateBranch({
+                ...context.repo,
+                pull_number: parseInt(${{ steps.find-pull-request.outputs.number }})
+              })
+              console.log(updateBranch.data.message)
+            } else {
+              console.log(`Branch is already up-to-date`)
+            }
+
       - name: Send Slack notification if workflow fails
         uses: someimportantcompany/github-actions-slack-message@0b470c14b39da4260ed9e3f9a4f1298a74ccdefd
         if: failure()

.github/workflows/triage-unallowed-contributions.yml

@@ -0,0 +1,122 @@
+name: Check unallowed file changes
+
+on:
+  pull_request_target:
+    paths:
+      - '.github/workflows/**'
+      - '.github/CODEOWNERS'
+      - 'translations/**'
+      - 'assets/fonts/**'
+      - 'data/graphql/**'
+      - 'lib/graphql/**'
+      - 'lib/redirects/**'
+      - 'lib/rest/**'
+      - 'lib/webhooks/**'
+
+jobs:
+  triage:
+    if: github.repository == 'github/docs' && github.event.pull_request.user.login != 'Octomerger'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f
+      - name: Check for existing requested changes
+        id: requested-change
+        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+        with:
+          github-token: ${{secrets.GITHUB_TOKEN}}
+          result-encoding: json
+          script: |
+            const pullReviews = await github.pulls.listReviews({
+              ...context.repo,
+              pull_number: context.payload.number
+            })
+
+            const botReviews = pullReviews.data
+              .filter(review => review.user.login === 'github-actions[bot]')
+              .sort((a, b) => new Date(b.submitted_at) - new Date(a.submitted_at))
+              .shift()
+
+            if (botReviews) {
+              console.log(`Pull request reviews authored by the github-action bot: ${botReviews}`)
+            }
+            return botReviews
+
+      - name: Get files changed
+        uses: dorny/paths-filter@eb75a1edc117d3756a18ef89958ee59f9500ba58
+        id: filter
+        with:
+          # Base branch used to get changed files
+          base: 'main'
+
+          # Enables setting an output in the format in `${FILTER_NAME}_files
+          # with the names of the matching files formatted as JSON array
+          list-files: json
+
+          # Returns list of changed files matching each filter
+          filters: |
+            translation:
+              - 'translations/**'
+            openapi:
+              - 'lib/rest/static/**'
+            notAllowed:
+              - '.github/workflows/**'
+              - '.github/CODEOWNERS'
+              - 'translations/**'
+              - 'assets/fonts/**'
+              - 'data/graphql/**'
+              - 'lib/graphql/**'
+              - 'lib/redirects/**'
+              - 'lib/rest/**'
+              - 'lib/webhooks/**'
+
+      # When there are changes to files we can't accept
+      # and no review exists,leave a REQUEST_CHANGES review
+      - name: Request pull request changes
+        # Check for no reviews or reviews that aren't CHANGES_REQUESTED
+        if: ${{ steps.filter.outputs.notAllowed == 'true' && (!steps.requested-change.outputs.result || fromJson(steps.requested-change.outputs.result).state != 'CHANGES_REQUESTED') }}
+        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+        with:
+          github-token: ${{secrets.GITHUB_TOKEN}}
+          script: |
+            const changedFiles = ${{steps.filter.outputs.notAllowed_files}}
+            const restFiles = ${{steps.filter.outputs.openapi_files}}
+            const translationFiles = ${{steps.filter.outputs.translation_files}}
+            const markdownFiles = changedFiles.map(file => `- \`${file}\`\n`).join('')
+
+            let reviewMessage = `👋 Hey there spelunker. It looks like you've modified some files that we can't accept as contributions.\n${markdownFiles}\n\nYou'll need to revert all of these ☝️ files using [GitHub Desktop](https://docs.github.com/en/free-pro-team@latest/desktop/contributing-and-collaborating-using-github-desktop/reverting-a-commit) or \`git checkout origin/main <file name>\`. Once you get those files reverted, we can continue with the review process. :octocat:`
+
+            if (restFiles.length > 0) {
+              reviewMessage += "\n\nIt looks like you've modified the OpenAPI schema (`lib/rest/static/**`). While we aren't accepting changes to the schema directly, you can open an issue for any updates to the REST API docs. Head on over to the [`github/rest-api-description`](https://github.com/github/rest-api-description/issues/new?assignees=&labels=Inaccuracy&template=schema-inaccuracy.md&title=%5BSchema+Inaccuracy%5D+%3CDescribe+Problem%3E) repository to open an issue. ⚡"
+            }
+
+            if (translationFiles.length > 0) {
+              await github.issues.addLabels({
+                ...context.repo,
+                issue_number: context.payload.number,
+                labels: ['localization']
+              })
+              reviewMessage += "\n\nIt looks like you've modified translated content. Unfortunately, we are not able to accept pull requests for translated content. Our translation process involves an integration with an external service at crowdin.com, where all translation activity happens. We hope to eventually open up the translation process to the open source community, but we're not there yet. See https://github.com/github/docs/blob/main/CONTRIBUTING.md#earth_asia-translations for more details."
+            }
+
+            await github.pulls.createReview({
+              ...context.repo,
+              pull_number: context.payload.number,
+              body: reviewMessage,
+              event: 'REQUEST_CHANGES'
+            })
+      # When the most recent review was CHANGES_REQUESTED and the existing
+      # PR no longer contains unallowed changes, dismiss the previous review
+      - name: Dismiss pull request review
+        # Check that unallowed files aren't modified and that a
+        # CHANGES_REQUESTED review already exists
+        if: ${{ steps.filter.outputs.notAllowed == 'false' && steps.requested-change.outputs.result && fromJson(steps.requested-change.outputs.result).state == 'CHANGES_REQUESTED' }}
+        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+        with:
+          github-token: ${{secrets.GITHUB_TOKEN}}
+          script: |
+            await github.pulls.dismissReview({
+              ...context.repo,
+              pull_number: context.payload.number,
+              review_id: ${{fromJson(steps.requested-change.outputs.result).id}},
+              message: `✨Looks like you reverted all files we don't accept contributions for. 🙌 A member of the docs team will review your PR soon. 🚂`
+            })

.github/workflows/update-graphql-files.yml

@@ -9,6 +9,7 @@ env:
   FREEZE: ${{ secrets.FREEZE }}
 
 on:
+  workflow_dispatch:
   schedule:
     - cron: '20 16 * * *' # run every day at 16:20 UTC / 8:20 PST
 
@@ -36,15 +37,15 @@ jobs:
       - name: Run updater scripts
         env:
           # need to use a token from a user with access to github/github for this step
-          GITHUB_TOKEN: ${{ secrets.ZEKE_PAT_WITH_REPO_AND_WORKFLOW_SCOPE_FOR_REPO_SYNC }}
+          GITHUB_TOKEN: ${{ secrets.RACHMARI_REPO_WORKFLOW }}
         run: |
           script/graphql/update-files.js
       - name: Create pull request
         id: create-pull-request
-        uses: peter-evans/create-pull-request@938e6aea6f8dbdaced2064e948cb806c77fe87b8
+        uses: peter-evans/create-pull-request@8c603dbb04b917a9fc2dd991dc54fef54b640b43
         with:
           # need to use a token with repo and workflow scopes for this step
-          token: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}
+          token: ${{ secrets.GITHUB_TOKEN }}
           commit-message: 'Action ran graphql script"update-files"'
           title: GraphQL schema update
           body:

CONTRIBUTING.md

@@ -152,7 +152,7 @@ We (usually the docs team, but sometimes GitHub product managers, engineers, or
 You should always review your own PR first.
 
 For content changes, make sure that you:
-- [ ] Confirm that the changes address every part of the content strategy plan from your issue (if there are differences, explain them).
+- [ ] Confirm that the changes address every part of the content design plan from your issue (if there are differences, explain them).
 - [ ] Review the content for technical accuracy.
 - [ ] Review the entire pull request using the [localization checklist](contributing/localization-checklist.md).
 - [ ] Copy-edit the changes for grammar, spelling, and adherence to the style guide.

Gemfile.lock

@@ -10,10 +10,11 @@ GEM
 
 PLATFORMS
   ruby
+  x86_64-linux
 
 DEPENDENCIES
   graphql (= 1.10.6)
   graphql-schema_comparator (~> 1.0.0)
 
 BUNDLED WITH
-   2.1.4
+   2.2.1

app.json

@@ -2,7 +2,8 @@
   "name": "docs.github.com",
   "env": {
     "NODE_ENV": "production",
-    "NPM_CONFIG_PRODUCTION": "true"
+    "NPM_CONFIG_PRODUCTION": "true",
+    "ENABLED_LANGUAGES": "en"
   },
   "buildpacks": [
     { "url": "heroku/nodejs" }

content/README.md

@@ -20,6 +20,7 @@ See the [contributing docs](/CONTRIBUTING.md) for general information about work
   - [`showMiniToc`](#showminitoc)
   - [`miniTocMaxHeadingLevel`](#minitocmaxheadinglevel)
   - [`allowTitleToDifferFromFilename`](#allowtitletodifferfromfilename)
+  - [`defaultPlatform`](#defaultplatform)
   - [Escaping single quotes](#escaping-single-quotes)
 - [Autogenerated mini TOCs](#autogenerated-mini-tocs)
 - [Versioning](#versioning)
@@ -172,6 +173,18 @@ featuredLinks:
 - Type: `Array`, items are objects `{ href: string, title: string, date: 'YYYY-MM-DD' }`
 - Optional.
 
+### `defaultPlatform`
+
+- Purpose: Override the initial platform selection for a page. If this frontmatter is omitted, then the platform-specific content matching the reader's operating system is shown by default. This behavior can be changed for individual pages, for which a manual selection is more reasonable. For example, most GitHub Actions runners use Linux and their operating system is independent of the reader's operating system.
+- Type: `String`, one of: `mac`, `windows`, `linux`.
+- Optional.
+
+Example:
+
+```yaml
+defaultPlatform: linux
+```
+
 ### Escaping single quotes
 
 If you see two single quotes in a row (`''`) in YML frontmatter where you might expect to see one (`'`), this is the YML-preferred way to escape a single quote. From [the YAML spec](https://yaml.org/spec/history/2001-12-10.html):

content/actions/creating-actions/creating-a-javascript-action.md

@@ -176,7 +176,7 @@ git tag -a -m "My first action release" v1
 git push --follow-tags
 ```
 
-As an alternative to checking in your `node_modules` directory you can use a tool called [`@vercel/ncc`](https://github.com/vercel/ncc) to compile your code and modules into one file used for distribution.
+Checking in your `node_modules` directory can cause problems. As an alternative, you can use a tool called [`@vercel/ncc`](https://github.com/vercel/ncc) to compile your code and modules into one file used for distribution.
 
 1. Install `vercel/ncc` by running this command in your terminal.
   `npm i -g @vercel/ncc`

content/actions/creating-actions/metadata-syntax-for-github-actions.md

@@ -117,6 +117,7 @@ runs:
 {% endraw %}
 
 #### `outputs.<output_id>.value`
+
 **Required** The value that the output parameter will be mapped to. You can set this to a `string` or an expression with context. For example, you can use the `steps` context to set the `value` of an output to the output value of a step.
 
 For more information on how to use context and expression syntax, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)".
@@ -205,9 +206,11 @@ For example, this `cleanup.js` will only run on Linux-based runners:
 
 **Required** The run steps that you plan to run in this action.
 
-##### `runs.steps.run`
+##### `runs.steps[*].run`
 
 **Required** The command you want to run. This can be inline or a script in your action repository:
+
+{% raw %}
 ```yaml
 runs:
   using: "composite"
@@ -215,6 +218,7 @@ runs:
     - run: ${{ github.action_path }}/test/script.sh
       shell: bash
 ```
+{% endraw %}
 
 Alternatively, you can use `$GITHUB_ACTION_PATH`:
 
@@ -228,23 +232,23 @@ runs:
 
 For more information, see "[`github context`](/actions/reference/context-and-expression-syntax-for-github-actions#github-context)".
 
-##### `runs.steps.shell`
+##### `runs.steps[*].shell`
 
 **Required** The shell where you want to run the command. You can use any of the shells listed [here](/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell).
 
-##### `runs.steps.name`
+##### `runs.steps[*].name`
 
 **Optional** The name of the composite run step.
 
-##### `runs.steps.id`
+##### `runs.steps[*].id`
 
 **Optional** A unique identifier for the step. You can use the `id` to reference the step in contexts. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)".
 
-##### `runs.steps.env`
+##### `runs.steps[*].env`
 
 **Optional**  Sets a `map` of environment variables for only that step. If you want to modify the environment variable stored in the workflow, use {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" %}`echo "{name}={value}" >> $GITHUB_ENV`{% else %}`echo "::set-env name={name}::{value}"`{% endif %} in a composite run step.
 
-##### `runs.steps.working-directory`
+##### `runs.steps[*].working-directory`
 
 **Optional**  Specifies the working directory where the command is run.
 

content/actions/guides/about-continuous-integration.md

@@ -25,7 +25,7 @@ Building and testing your code requires a server. You can build and test updates
 
 ### About continuous integration using {% data variables.product.prodname_actions %}
 
-CI using {% data variables.product.prodname_actions %} offers workflows that can build the code in your repository and run your tests. Workflows can run on {% data variables.product.prodname_dotcom %}-hosted virtual machines, or on machines that you host yourself. For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)," and "[About self-hosted runners](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)."
+CI using {% data variables.product.prodname_actions %} offers workflows that can build the code in your repository and run your tests. Workflows can run on {% data variables.product.prodname_dotcom %}-hosted virtual machines, or on machines that you host yourself. For more information, see "[Virtual environments for {% data variables.product.prodname_dotcom %}-hosted runners](/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners)" and "[About self-hosted runners](/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners)."
 
 You can configure your CI workflow to run when a {% data variables.product.product_name %} event occurs (for example, when new code is pushed to your repository), on a set schedule, or when an external event occurs using the repository dispatch webhook.
 

content/actions/guides/building-and-testing-java-with-maven.md

@@ -53,7 +53,7 @@ jobs:
         with:
           java-version: 1.8
       - name: Build with Maven
-        run: mvn -B package --file pom.xml
+        run: mvn --batch-mode --update-snapshots verify
 ```
 {% endraw %}
 
@@ -85,7 +85,7 @@ steps:
     with:
       java-version: 1.8
   - name: Run the Maven verify phase
-    run: mvn -B verify --file pom-ci.xml
+    run: mvn --batch-mode --update-snapshots verify
 ```
 {% endraw %}
 
@@ -108,7 +108,7 @@ steps:
       key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
       restore-keys: ${{ runner.os }}-m2
   - name: Build with Maven
-    run: mvn -B package --file pom.xml
+    run: mvn --batch-mode --update-snapshots verify
 ```
 {% endraw %}
 
@@ -125,7 +125,7 @@ Maven will usually create output files like JARs, EARs, or WARs in the `target`
 steps:
   - uses: actions/checkout@v2
   - uses: actions/setup-java@v1
-  - run: mvn -B package --file pom.xml
+  - run: mvn --batch-mode --update-snapshots verify
   - run: mkdir staging && cp target/*.jar staging
   - uses: actions/upload-artifact@v2
     with:

content/actions/guides/building-and-testing-nodejs.md

@@ -193,9 +193,9 @@ steps:
 
 {% data reusables.github-actions.setup-node-intro %}
 
-To authenticate to your private registry, you'll need to store your npm authentication token as a secret in your repository settings. For example, create a secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+To authenticate to your private registry, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 
-In the example below, the secret `NPM_TOKEN` stores the npm authentication token. The `setup-node` action configures the *.npmrc* file to read the npm authentication token from the `NODE_AUTH_TOKEN` environment variable. When using the `setup-node` action to create an *.npmrc* file, you must set the `NPM_AUTH_TOKEN` environment variable with the secret that contains your npm authentication token.
+In the example below, the secret `NPM_TOKEN` stores the npm authentication token. The `setup-node` action configures the *.npmrc* file to read the npm authentication token from the `NODE_AUTH_TOKEN` environment variable. When using the `setup-node` action to create an *.npmrc* file, you must set the `NODE_AUTH_TOKEN` environment variable with the secret that contains your npm authentication token.
 
 Before installing dependencies, use the `setup-node` action to create the *.npmrc* file. The action has two input parameters. The `node-version` parameter sets the Node.js version, and the `registry-url` parameter sets the default registry. If your package registry uses scopes, you must use the `scope` parameter. For more information, see [`npm-scope`](https://docs.npmjs.com/misc/scope).
 

content/actions/guides/building-and-testing-powershell.md

@@ -214,7 +214,7 @@ The `always()` function configures the job to continue processing even if there
 
 ### Publishing to PowerShell Gallery
 
-You can configure your workflow to publish your PowerShell module to the PowerShell Gallery when your CI tests pass. You can use repository secrets to store any tokens or credentials needed to publish your package. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+You can configure your workflow to publish your PowerShell module to the PowerShell Gallery when your CI tests pass. You can use secrets to store any tokens or credentials needed to publish your package. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 
 The following example creates a package and uses `Publish-Module` to publish it to the PowerShell Gallery:
 

content/actions/guides/building-and-testing-python.md

@@ -391,7 +391,7 @@ jobs:
 
 You can configure your workflow to publish your Python package to any package registry you'd like when your CI tests pass.
 
-You can store any access tokens or credentials needed to publish your package using repository secrets. The following example creates and publishes a package to PyPI using `twine` and `dist`. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+You can store any access tokens or credentials needed to publish your package using secrets. The following example creates and publishes a package to PyPI using `twine` and `dist`. For more information, see "[Creating and using encrypted secrets](/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 
 {% raw %}
 ```yaml

content/actions/guides/deploying-to-amazon-elastic-container-service.md

@@ -0,0 +1,150 @@
+---
+title: Deploying to Amazon Elastic Container Service
+intro: You can deploy to Amazon Elastic Container Service (ECS) as part of your continuous deployment (CD) workflows.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+### Introduction
+
+This guide explains how to use {% data variables.product.prodname_actions %} to build a containerized application, push it to [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/), and deploy it to [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/).
+
+On every new release in your {% data variables.product.company_short %} repository, the {% data variables.product.prodname_actions %} workflow builds and pushes a new container image to Amazon ECR, and then deploys a new task definition to Amazon ECS.
+
+### Prerequisites
+
+Before creating your {% data variables.product.prodname_actions %} workflow, you will first need to complete the following setup steps for Amazon ECR and ECS:
+
+1. Create an Amazon ECR repository to store your images.
+
+   For example, using [the AWS CLI](https://aws.amazon.com/cli/):
+
+   {% raw %}```bash{:copy}
+   aws ecr create-repository \
+       --repository-name MY_ECR_REPOSITORY \
+       --region MY_AWS_REGION
+   ```{% endraw %}
+
+   Ensure that you use the same Amazon ECR repository name (represented here by `MY_ECR_REPOSITORY`) for the `ECR_REPOSITORY` variable in the workflow below.
+
+   Ensure that you use the same AWS region value for the `AWS_REGION` (represented here by `MY_AWS_REGION`) variable in the workflow below.
+
+2. Create an Amazon ECS task definition, cluster, and service.
+
+   For details, follow the [Getting started wizard on the Amazon ECS console](https://us-east-2.console.aws.amazon.com/ecs/home?region=us-east-2#/firstRun), or the [Getting started guide](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/getting-started-fargate.html) in the Amazon ECS documentation.
+
+   Ensure that you note the names you set for the Amazon ECS service and cluster, and use them for the `ECS_SERVICE` and `ECS_CLUSTER` variables in the workflow below.
+
+3. Store your Amazon ECS task definition as a JSON file in your {% data variables.product.company_short %} repository.
+
+   The format of the file should be the same as the output generated by:
+
+   {% raw %}```bash{:copy}
+   aws ecs register-task-definition --generate-cli-skeleton
+   ```{% endraw %}
+
+   Ensure that you set the `ECS_TASK_DEFINITION` variable in the workflow below as the path to the JSON file.
+
+   Ensure that you set the `CONTAINER_NAME` variable in the workflow below as the container name in the `containerDefinitions` section of the task definition.
+
+4. Create {% data variables.product.prodname_actions %} secrets named `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to store the values for your Amazon IAM access key.
+
+   For more information on creating secrets for {% data variables.product.prodname_actions %}, see "[Encrypted secrets](/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository)."
+
+   See the documentation for each action used below for the recommended IAM policies for the IAM user, and methods for handling the access key credentials.
+
+### Creating the workflow
+
+Once you've completed the prerequisites, you can proceed with creating the workflow.
+
+The following example workflow demonstrates how to build a container image and push it to Amazon ECR. It then updates the task definition with the new image ID, and deploys the task definition to Amazon ECS.
+
+Ensure that you provide your own values for all the variables in the `env` key of the workflow.
+
+{% raw %}
+```yaml{:copy}
+name: Deploy to Amazon ECS
+
+on:
+  release:
+    types: [ created ]
+
+env:
+  AWS_REGION: MY_AWS_REGION                   # set this to your preferred AWS region, e.g. us-west-1
+  ECR_REPOSITORY: MY_ECR_REPOSITORY           # set this to your Amazon ECR repository name
+  ECS_SERVICE: MY_ECS_SERVICE                 # set this to your Amazon ECS service name
+  ECS_CLUSTER: MY_ECS_CLUSTER                 # set this to your Amazon ECS cluster name
+  ECS_TASK_DEFINITION: MY_ECS_TASK_DEFINITION # set this to the path to your Amazon ECS task definition
+                                               # file, e.g. .aws/task-definition.json
+  CONTAINER_NAME: MY_CONTAINER_NAME           # set this to the name of the container in the
+                                               # containerDefinitions section of your task definition
+
+defaults:
+  run:
+    shell: bash
+
+jobs:
+  deploy:
+    name: Deploy
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+
+      - name: Configure AWS credentials
+        uses: aws-actions/configure-aws-credentials@v1
+        with:
+          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
+          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+          aws-region: $AWS_REGION
+
+      - name: Login to Amazon ECR
+        id: login-ecr
+        uses: aws-actions/amazon-ecr-login@v1
+
+      - name: Build, tag, and push image to Amazon ECR
+        id: build-image
+        env:
+          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
+          IMAGE_TAG: ${{ github.sha }}
+        run: |
+          # Build a docker container and
+          # push it to ECR so that it can
+          # be deployed to ECS.
+          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
+          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
+          echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_ENV
+
+      - name: Fill in the new image ID in the Amazon ECS task definition
+        id: task-def
+        uses: aws-actions/amazon-ecs-render-task-definition@v1
+        with:
+          task-definition: $ECS_TASK_DEFINITION
+          container-name: $CONTAINER_NAME
+          image: ${{ steps.build-image.outputs.image }}
+
+      - name: Deploy Amazon ECS task definition
+        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
+        with:
+          task-definition: ${{ steps.task-def.outputs.task-definition }}
+          service: $ECS_SERVICE
+          cluster: $ECS_CLUSTER
+          wait-for-service-stability: true
+```
+{% endraw %}
+
+### Additional resources
+
+For more information on the services used in these examples, see the following documentation:
+
+* "[Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)" in the Amazon AWS documentation.
+* Official AWS "[Configure AWS Credentials](https://github.com/aws-actions/configure-aws-credentials)" action.
+* Official AWS [Amazon ECR "Login"](https://github.com/aws-actions/amazon-ecr-login) action.
+* Official AWS [Amazon ECS "Render Task Definition"](https://github.com/aws-actions/amazon-ecs-render-task-definition) action.
+* Official AWS [Amazon ECS "Deploy Task Definition"](https://github.com/aws-actions/amazon-ecs-deploy-task-definition) action.

content/actions/guides/deploying-to-azure-app-service.md

@@ -0,0 +1,115 @@
+---
+title: Deploying to Azure App Service
+intro: You can deploy to Azure App Service as part of your continuous deployment (CD) workflows.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+### Introduction
+
+This guide explains how to use {% data variables.product.prodname_actions %} to build, test, and deploy an application to [Azure App Service](https://azure.microsoft.com/en-us/services/app-service/).
+
+Azure App Service can run web apps in several languages, but this guide demonstrates deploying an existing Node.js project.
+
+### Prerequisites
+
+Before creating your {% data variables.product.prodname_actions %} workflow, you will first need to complete the following setup steps:
+
+1. Create an Azure App Service plan.
+
+   For example, you can use the Azure CLI to create a new App Service plan:
+
+   ```bash{:copy}
+   az appservice plan create \
+       --resource-group MY_RESOURCE_GROUP \
+       --name MY_APP_SERVICE_PLAN \
+       --is-linux
+   ```
+
+   In the command above, replace `MY_RESOURCE_GROUP` with your pre-existing Azure Resource Group, and `MY_APP_SERVICE_PLAN` with a new name for the App Service plan.
+
+   See the Azure documentation for more information on using the [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/):
+
+   * For authentication, see "[Sign in with Azure CLI](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli)".
+   * If you need to create a new resource group, see "[az group](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create)."
+
+2. Create a web app.
+
+   For example, you can use the Azure CLI to create an Azure App Service web app with a node runtime:
+
+   ```bash{:copy}
+   az webapp create \
+       --name MY_WEBAPP_NAME \
+       --plan MY_APP_SERVICE_PLAN \
+       --resource-group MY_RESOURCE_GROUP \
+       --runtime "node|10.14"
+   ```
+
+   In the command above, replace the parameters with your own values, where `MY_WEBAPP_NAME` is a new name for the web app.
+
+3. Configure an Azure publish profile and create an `AZURE_WEBAPP_PUBLISH_PROFILE` secret.
+
+   Generate your Azure deployment credentials using a publish profile. For more information, see "[Generate deployment credentials](https://docs.microsoft.com/en-us/azure/app-service/deploy-github-actions?tabs=applevel#generate-deployment-credentials)" in the Azure documentation. 
+
+   In your {% data variables.product.prodname_dotcom %} repository, create a secret named `AZURE_WEBAPP_PUBLISH_PROFILE` that contains the contents of the publish profile. For more information on creating secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository)."
+
+### Creating the workflow
+
+Once you've completed the prerequisites, you can proceed with creating the workflow.
+
+The following example workflow demonstrates how to build, test, and deploy the Node.js project to Azure App Service.
+
+Ensure that you set `AZURE_WEBAPP_NAME` in the workflow `env` key to the name of the web app you created.
+
+{% raw %}
+```yaml{:copy}
+on:
+  release:
+    types: [created]
+
+env:
+  AZURE_WEBAPP_NAME: MY_WEBAPP_NAME   # set this to your application's name
+  AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
+  NODE_VERSION: '10.x'                # set this to the node version to use
+
+jobs:
+  build-and-deploy:
+    name: Build and Deploy
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Use Node.js ${{ env.NODE_VERSION }}
+        uses: actions/setup-node@v1
+        with:
+          node-version: ${{ env.NODE_VERSION }}
+
+      - name: npm install, build, and test
+        run: |
+          # Build and test the project, then
+          # deploy to Azure Web App.
+          npm install
+          npm run build --if-present
+          npm run test --if-present
+
+      - name: 'Deploy to Azure WebApp'
+        uses: azure/webapps-deploy@v2
+        with:
+          app-name: ${{ env.AZURE_WEBAPP_NAME }}
+          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
+          package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
+```
+{% endraw %}
+
+### Additional resources
+
+The following resources may also be useful:
+
+* For the original starter workflow, see [`azure.yml`](https://github.com/actions/starter-workflows/blob/master/ci/azure.yml) in the {% data variables.product.prodname_actions %} `starter-workflows` repository.
+* The action used to deploy the web app is the official Azure [`Azure/webapps-deploy`](https://github.com/Azure/webapps-deploy) action.
+* The "[Create a Node.js web app in Azure](https://docs.microsoft.com/en-us/azure/app-service/quickstart-nodejs)" quickstart in the Azure web app documentation demonstrates using VS Code with the [Azure App Service extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azureappservice).

content/actions/guides/deploying-to-google-kubernetes-engine.md

@@ -0,0 +1,177 @@
+---
+title: Deploying to Google Kubernetes Engine
+intro: You can deploy to Google Kubernetes Engine as part of your continuous deployment (CD) workflows.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+
+### Introduction
+
+This guide explains how to use {% data variables.product.prodname_actions %} to build a containerized application, push it to Google Container Registry (GCR), and deploy it to Google Kubernetes Engine (GKE).
+
+GKE is a managed Kubernetes cluster service from Google Cloud that can host your containerized workloads in the cloud or in your own datacenter. For more information, see [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine).
+
+### Prerequisites
+
+Before you proceed with creating the workflow, you will need to complete the following steps for your Kubernetes project. This guide assumes the root of your project already has a `Dockerfile` and a Kubernetes Deployment configuration file. For an example, see [google-github-actions](https://github.com/google-github-actions/setup-gcloud/tree/master/example-workflows/gke).
+
+#### Creating a GKE cluster
+
+To create the GKE cluster, you will first need to authenticate using the `gcloud` CLI. For more information on this step, see the following articles:
+- [`gcloud auth login`](https://cloud.google.com/sdk/gcloud/reference/auth/login)
+- [`gcloud` CLI](https://cloud.google.com/sdk/gcloud/reference)
+- [`gcloud` CLI and Cloud SDK](https://cloud.google.com/sdk/gcloud#the_gcloud_cli_and_cloud_sdk)
+
+For example:
+
+{% raw %}
+```bash{:copy}
+$ gcloud container clusters create $GKE_CLUSTER \
+	--project=$GKE_PROJECT \
+	--zone=$GKE_ZONE
+```
+{% endraw %}
+
+#### Enabling the APIs
+
+Enable the Kubernetes Engine and Container Registry APIs. For example:
+
+{% raw %}
+```bash{:copy}
+$ gcloud services enable \
+	containerregistry.googleapis.com \
+	container.googleapis.com
+```
+{% endraw %}
+
+#### Configuring a service account and storing its credentials
+
+This procedure demonstrates how to create the service account for your GKE integration. It explains how to create the account, add roles to it, retrieve its keys, and store them as a base64-encoded [encrypted repository secret](/actions/reference/encrypted-secrets) named `GKE_SA_KEY`.
+
+1. Create a new service account:
+  {% raw %}
+  ```
+  $ gcloud iam service-accounts create $SA_NAME
+  ```
+  {% endraw %}
+1. Retrieve the email address of the service account you just created:
+  {% raw %}
+  ```
+  $ gcloud iam service-accounts list
+  ```
+  {% endraw %}
+1. Add roles to the service account. Note: Apply more restrictive roles to suit your requirements.
+  {% raw %}
+  ```
+  $ gcloud projects add-iam-policy-binding $GKE_PROJECT \
+    --member=serviceAccount:$SA_EMAIL \
+    --role=roles/container.admin \
+    --role=roles/storage.admin
+  ```
+  {% endraw %}
+1. Download the JSON keyfile for the service account:
+  {% raw %}
+  ```
+  $ gcloud iam service-accounts keys create key.json --iam-account=$SA_EMAIL
+  ```
+  {% endraw %}
+1. Store the project ID as a secret named `GKE_PROJECT`:
+  {% raw %}
+  ```
+  $ export GKE_SA_KEY=$(cat key.json | base64)
+  ```
+  {% endraw %}
+
+#### (Optional) Configuring kustomize
+Kustomize is an optional tool used for managing YAML specs. After creating a _kustomization_ file, the workflow below can be used to dynamically set fields of the image and pipe in the result to `kubectl`. For more information, see [kustomize usage](https://github.com/kubernetes-sigs/kustomize#usage).
+
+### Creating the workflow
+
+Once you've completed the prerequisites, you can proceed with creating the workflow.
+
+The following example workflow demonstrates how to build a container image and push it to GCR. It then uses the Kubernetes tools (such as `kubectl` and `kustomize`) to pull the image into the cluster deployment.
+
+{% raw %}
+```yaml{:copy}
+name: Build and Deploy to GKE
+ 
+on:
+  release:
+    types: [created]
+ 
+env:
+  PROJECT_ID: ${{ secrets.GKE_PROJECT }}
+  GKE_CLUSTER: cluster-1    # Add your cluster name here.
+  GKE_ZONE: us-central1-c   # Add your cluster zone here.
+  DEPLOYMENT_NAME: gke-test # Add your deployment name here.
+  IMAGE: static-site
+ 
+jobs:
+  setup-build-publish-deploy:
+    name: Setup, Build, Publish, and Deploy
+    runs-on: ubuntu-latest
+    steps:
+ 
+    - name: Checkout
+      uses: actions/checkout@v2
+ 
+    # Setup gcloud CLI
+    - uses: google-github-actions/setup-gcloud@v0.2.0
+      with:
+        service_account_key: ${{ secrets.GKE_SA_KEY }}
+        project_id: ${{ secrets.GKE_PROJECT }}
+ 
+    # Configure docker to use the gcloud command-line tool as a credential helper
+    - run: |-
+        gcloud --quiet auth configure-docker
+      
+    # Get the GKE credentials so we can deploy to the cluster
+    - uses: google-github-actions/get-gke-credentials@v0.2.1
+      with:
+        cluster_name: ${{ env.GKE_CLUSTER }}
+        location: ${{ env.GKE_ZONE }}
+        credentials: ${{ secrets.GKE_SA_KEY }}
+
+    # Build the Docker image
+    - name: Build
+      run: |-
+        docker build \
+          --tag "gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA" \
+          --build-arg GITHUB_SHA="$GITHUB_SHA" \
+          --build-arg GITHUB_REF="$GITHUB_REF" \
+          .
+ 
+    # Push the Docker image to Google Container Registry
+    - name: Publish
+      run: |-
+        docker push "gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA"
+        
+    # Set up kustomize
+    - name: Set up Kustomize
+      run: |-
+        curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v3.1.0/kustomize_3.1.0_linux_amd64
+        chmod u+x ./kustomize
+ 
+    # Deploy the Docker image to the GKE cluster
+    - name: Deploy
+      run: |-
+        ./kustomize edit set image gcr.io/PROJECT_ID/IMAGE:TAG=gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA
+        ./kustomize build . | kubectl apply -f -
+        kubectl rollout status deployment/$DEPLOYMENT_NAME
+        kubectl get services -o wide
+```
+{% endraw %}
+
+### Additional resources
+
+For more information on the tools used in these examples, see the following documentation:
+
+* For the full starter workflow, see the ["Build and Deploy to GKE" workflow](https://github.com/actions/starter-workflows/blob/master/ci/google.yml).
+* For more starter workflows and accompanying code, see Google's [{% data variables.product.prodname_actions %} example workflows](https://github.com/google-github-actions/setup-gcloud/tree/master/example-workflows/).
+* The Kubernetes YAML customization engine: [Kustomize](https://kustomize.io/).
+* "[Deploying a containerized web application](https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app)" in the Google Kubernetes Engine documentation.

content/actions/guides/index.md

@@ -36,6 +36,14 @@ You can use {% data variables.product.prodname_actions %} to create custom conti
 {% link_in_list /building-and-testing-java-with-gradle %}
 {% link_in_list /building-and-testing-java-with-ant %}
 
+### Creating custom continuous deployment workflows
+
+You can use {% data variables.product.prodname_actions %} to create custom continuous deployment (CD) workflows that deploy projects to a number of cloud partner ecosystems.
+
+ {% link_in_list /deploying-to-amazon-elastic-container-service %}
+ {% link_in_list /deploying-to-azure-app-service %}
+ {% link_in_list /deploying-to-google-kubernetes-engine %}
+
 ### Publishing software packages
 
 You can automate publishing software packages as part your continuous delivery (CD) workflow. Packages can be published to any package host and to {% data reusables.gated-features.packages %}.

content/actions/guides/publishing-docker-images.md

@@ -46,11 +46,11 @@ In this guide, we will use the Docker `build-push-action` action to build the Do
 
 In the example workflow below, we use the Docker `build-push-action` action to build the Docker image and, if the build succeeds, push the built image to Docker Hub.
 
-To push to Docker Hub, you will need to have a Docker Hub account, and have a Docker Hub repository created. For more information, see "[Share images on Docker Hub](https://docs.docker.com/get-started/part3/)" in the Docker documentation.
+To push to Docker Hub, you will need to have a Docker Hub account, and have a Docker Hub repository created. For more information, see "[Pushing a Docker container image to Docker Hub](https://docs.docker.com/docker-hub/repos/#pushing-a-docker-container-image-to-docker-hub)" in the Docker documentation.
 
 The `build-push-action` options required for Docker Hub are:
 
-* `username` and `password`: This is your Docker Hub username and password. We recommend storing your Docker Hub username and password as encrypted secrets in your {% data variables.product.prodname_dotcom %} repository so they aren't exposed in your workflow file. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+* `username` and `password`: This is your Docker Hub username and password. We recommend storing your Docker Hub username and password as secrets so they aren't exposed in your workflow file. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 * `repository`: Your Docker Hub repository in the format `DOCKER-HUB-NAMESPACE/DOCKER-HUB-REPOSITORY`.
 
 {% raw %}

content/actions/guides/publishing-java-packages-with-maven.md

@@ -84,7 +84,7 @@ jobs:
           server-username: MAVEN_USERNAME
           server-password: MAVEN_PASSWORD
       - name: Publish package
-        run: mvn -B deploy
+        run: mvn --batch-mode deploy
         env:
           MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
           MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
@@ -143,7 +143,7 @@ jobs:
         with:
           java-version: 1.8
       - name: Publish package
-        run: mvn -B deploy
+        run: mvn --batch-mode deploy
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 ```
@@ -182,7 +182,7 @@ jobs:
           server-username: MAVEN_USERNAME
           server-password: MAVEN_PASSWORD
       - name: Publish to the Maven Central Repository
-        run: mvn -B deploy
+        run: mvn --batch-mode deploy
         env:
           MAVEN_USERNAME: ${{ secrets.OSSRH_USERNAME }}
           MAVEN_PASSWORD: ${{ secrets.OSSRH_TOKEN }}
@@ -191,7 +191,7 @@ jobs:
         with:
           java-version: 1.8
       - name: Publish to GitHub Packages
-        run: mvn -B deploy
+        run: mvn --batch-mode deploy
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 ```

content/actions/guides/publishing-nodejs-packages.md

@@ -44,7 +44,7 @@ If you add steps in your workflow to configure the `publishConfig` fields in you
 
 Each time you create a new release, you can trigger a workflow to publish your package. The workflow in the example below runs when the `release` event triggers with type `created`. The workflow publishes the package to the npm registry if CI tests pass.
 
-To perform authenticated operations against the npm registry in your workflow, you'll need to store your npm authentication token as a secret in your repository settings. For example, create a secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
+To perform authenticated operations against the npm registry in your workflow, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. For more information, see "[Creating and using encrypted secrets](/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)."
 
 By default, npm uses the `name` field of the *package.json* file to determine the npm registry. When publishing to a global namespace, you only need to include the package name. For example, you would publish a package named `npm-hello-world-test` to the `https://www.npmjs.com/package/npm-hello-world-test`.
 

content/actions/hosting-your-own-runners/configuring-the-self-hosted-runner-application-as-a-service.md

@@ -6,6 +6,7 @@ redirect_from:
 versions:
   free-pro-team: '*'
   enterprise-server: '>=2.22'
+defaultPlatform: linux
 ---
 
 {% data reusables.actions.enterprise-beta %}

content/actions/hosting-your-own-runners/monitoring-and-troubleshooting-self-hosted-runners.md

@@ -8,6 +8,7 @@ redirect_from:
 versions:
   free-pro-team: '*'
   enterprise-server: '>=2.22'
+defaultPlatform: linux
 ---
 
 {% data reusables.actions.enterprise-beta %}

content/actions/index.md

@@ -25,18 +25,15 @@ featuredLinks:
     - /actions/reference/workflow-commands-for-github-actions
     - /actions/reference/environment-variables
 changelog:
+  - title: Workflow visualization
+    date: '2020-12-08'
+    href: https://github.blog/changelog/2020-12-08-github-actions-workflow-visualization/
   - title: Removing set-env and add-path commands on November 16
     date: '2020-11-09'
     href: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
   - title: Ubuntu-latest workflows will use Ubuntu-20.04
     date: '2020-10-29'
     href: https://github.blog/changelog/2020-10-29-github-actions-ubuntu-latest-workflows-will-use-ubuntu-20-04
-  - title: MacOS Big Sur Preview
-    date: '2020-10-29'
-    href: https://github.blog/changelog/2020-10-29-github-actions-macos-big-sur-preview
-  - title: Self-Hosted Runner Group Access Changes
-    date: '2020-10-16'
-    href: https://github.blog/changelog/2020-10-16-github-actions-self-hosted-runner-group-access-changes/
 
 product_video: https://www.youtube-nocookie.com/embed/cP0I9w2coGU
   

content/actions/learn-github-actions/finding-and-customizing-actions.md

@@ -79,7 +79,7 @@ steps:
 
 #### Using branches
 
-Referring to a specific branch means that the action will always use include the latest updates on the target branch, but can create problems if those updates include breaking changes. This example targets a branch named `@main`:
+Referring to a specific branch means that the action will always use the latest updates on the target branch, but can create problems if those updates include breaking changes. This example targets a branch named `@main`:
 
 ```yaml
 steps:

content/actions/learn-github-actions/managing-complex-workflows.md

@@ -1,7 +1,7 @@
 ---
 title: Managing complex workflows
 shortTitle: Managing complex workflows
-intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices, and labels.'
+intro: 'This guide shows you how to use the advanced features of {% data variables.product.prodname_actions %}, with secret management, dependent jobs, caching, build matrices,{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} environments,{% endif %} and labels.'
 versions:
   free-pro-team: '*'
   enterprise-server: '>=2.22'
@@ -148,6 +148,12 @@ jobs:
 
 For more information, see  ["Using labels with self-hosted runners](/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)."
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+### Using environments
+
+You can configure environments with protection rules and secrets. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see "[Environments](/actions/reference/environments)."
+{% endif %}
+
 ### Next steps
 
 To continue learning about {% data variables.product.prodname_actions %}, see "[Sharing workflows with your organization](/actions/learn-github-actions/sharing-workflows-with-your-organization)."

content/actions/learn-github-actions/migrating-from-jenkins-to-github-actions.md

@@ -57,7 +57,7 @@ Jenkins uses directives to manage _Declarative Pipelines_. These directives defi
 
 | Jenkins Directives | {% data variables.product.prodname_actions %} |
 | ------------- | ------------- |
-| [`environment`](https://jenkins.io/doc/book/pipeline/syntax/#environment)  |  [`jobs.<job_id>.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) <br> [`jobs.<job_id>.steps.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv) |
+| [`environment`](https://jenkins.io/doc/book/pipeline/syntax/#environment)  |  [`jobs.<job_id>.env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) <br> [`jobs.<job_id>.steps[*].env`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv) |
 |  [`options`](https://jenkins.io/doc/book/pipeline/syntax/#parameters) |  [`jobs.<job_id>.strategy`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategy) <br> [`jobs.<job_id>.strategy.fail-fast`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast) <br> [`jobs.<job_id>.timeout-minutes`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes)|
 | [`parameters`](https://jenkins.io/doc/book/pipeline/syntax/#parameters)  | [`inputs`](/actions/creating-actions/metadata-syntax-for-github-actions#inputs) <br> [`outputs`](/actions/creating-actions/metadata-syntax-for-github-actions#outputs) |
 | [`triggers`](https://jenkins.io/doc/book/pipeline/syntax/#triggers)  | [`on`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#on) <br> [`on.<event_name>.types`](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onevent_nametypes) <br> [<code>on.<push\|pull_request>.<branches\|tags></code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestbranchestags) <br> [<code>on.<push\|pull_request>.paths</code>](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths) |

content/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions.md

@@ -176,7 +176,7 @@ When migrating from Travis CI, consider the following key features in {% data va
 
 #### Storing secrets
 
-{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} also includes policies that allow you to limit access to secrets at the repository and organization level. For more information, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+{% data variables.product.prodname_actions %} allows you to store secrets and reference them in your jobs. {% data variables.product.prodname_actions %} organizations can limit which repositories can access organization secrets. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}Environment protection rules can require manual approval for a workflow to access environment secrets. {% endif %}For more information, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
 
 #### Sharing files between jobs and workflows
 

content/actions/learn-github-actions/security-hardening-for-github-actions.md

@@ -19,7 +19,7 @@ This guide explains how to configure security hardening for certain {% data vari
 
 ### Using secrets
 
-Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets) can be configured at the organization or repository level, and allow you to store sensitive information in {% data variables.product.product_name %}.
+Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets) can be configured at the organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or environment{% else %} or repository{% endif %} level, and allow you to store sensitive information in {% data variables.product.product_name %}.
 
 Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.product_name %}. This occurs when the secret is submitted [using the UI](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets#creating-encrypted-secrets-for-a-repository) or through the [REST API](/rest/reference/actions#secrets). This client-side encryption helps the minimize risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.product_name %}'s infrastructure. Once the secret is uploaded, {% data variables.product.product_name %} is then able to decrypt it so that it can be injected into the workflow runtime. 
 
@@ -38,6 +38,10 @@ To help prevent accidental disclosure, {% data variables.product.product_name %}
 - **Audit and rotate registered secrets**
     - Periodically review the registered secrets to confirm they are still required. Remove those that are no longer needed.
     - Rotate secrets periodically to reduce the window of time during which a compromised secret is valid.
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+- **Consider requiring review for access to secrets**
+    - You can use required reviewers to protect environment secrets. A workflow job cannot access environment secrets until approval is granted by a reviewer. For more information about storing secrets in environments or requiring reviews for environments, see "[Encrypted secrets](/actions/reference/encrypted-secrets)" and "[Environments](/actions/reference/environments)."
+{% endif %}
 
 ### Using third-party actions
 
@@ -66,13 +70,13 @@ This means that a compromise of a single action within a workflow can be very si
 
 ### Considering cross-repository access
 
-{% data variables.product.product_name %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` used in the workflow environment grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to the workflow environment, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
+{% data variables.product.product_name %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
 
-We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow environment. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
+We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.
 
 This list describes the recommended approaches for accessing repository data within a workflow, in descending order of preference:
 
-1. **The `GITHUB_TOKEN` in the workflow environment**
+1. **The `GITHUB_TOKEN`**
     -  This token is intentionally scoped to the single repository that invoked the workflow, and has the same level of access as a write-access user on the repository. The token is created before each job begins and expires when the job is finished. For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
     - The `GITHUB_TOKEN` should be used whenever possible.
 2. **Repository deploy key**

content/actions/managing-workflow-runs/enabling-debug-logging.md

@@ -13,6 +13,9 @@ versions:
 These extra logs are enabled by setting secrets in the repository containing the workflow, so the same permissions requirements will apply:
 
 - {% data reusables.github-actions.permissions-statement-secrets-repository %}
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+- {% data reusables.github-actions.permissions-statement-secrets-environment %}
+{% endif %}
 - {% data reusables.github-actions.permissions-statement-secrets-organization %}
 - {% data reusables.github-actions.permissions-statement-secrets-api %}
 

content/actions/managing-workflow-runs/index.md

@@ -1,7 +1,7 @@
 ---
 title: Managing workflow runs
 shortTitle: Managing workflow runs
-intro: 'You can view the status and results of each step in your workflow, cancel a pending workflow, view billable job execution minutes, debug and re-run a failed workflow, search and download logs, and download artifacts.'
+intro: 'You can view the status and results of each step in your workflow, cancel a pending workflow, {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}review deployments, {% endif %}view billable job execution minutes, debug and re-run a failed workflow, search and download logs, and download artifacts.'
 redirect_from:
   - /actions/configuring-and-managing-workflows/managing-a-workflow-run
   - /articles/viewing-your-repository-s-workflows
@@ -24,6 +24,7 @@ versions:
 {% link_in_list /manually-running-a-workflow %}
 {% link_in_list /re-running-a-workflow %}
 {% link_in_list /canceling-a-workflow %}
+{% link_in_list /reviewing-deployments %}
 {% link_in_list /disabling-and-enabling-a-workflow %}
 {% link_in_list /deleting-a-workflow-run %}
 {% link_in_list /viewing-job-execution-time %}

content/actions/managing-workflow-runs/reviewing-deployments.md

@@ -0,0 +1,27 @@
+---
+title: Reviewing deployments
+intro: You can approve or reject jobs awaiting review.
+product: '{% data reusables.gated-features.environments %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=3.1'
+---
+
+{% data reusables.actions.environments-beta %}
+
+### About required reviews in workflows
+
+Jobs that reference an environment configured with required reviewers will wait for an approval before starting. While a job is awaiting approval, it has a status of "Waiting". If a job is not approved within 30 days, the workflow run will be automatically canceled.
+
+For more information about environments and required approvals, see "[Environments](/actions/reference/environments)."
+
+### Approving or rejecting a job
+
+1. Navigate to the workflow run that requires review. For more information about navigating to a workflow run, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
+2. Click **Review deployments**. 
+   ![Review deployments](/assets/images/actions-review-deployments.png)
+3. Select the job environment(s) to approve or reject. Optionally, leave a comment.
+   ![Approve deployments](/assets/images/actions-approve-deployments.png)
+4. Approve or reject:
+   - To approve the job, click **Approve and deploy**. Once a job is approved (and any other environment protection rules have passed), the job will proceed. At this point, the job can access any secrets stored in the environment.
+   - To reject the job, click **Reject**. If a job is rejected, the workflow will fail.

content/actions/quickstart.md

@@ -123,7 +123,7 @@ Printing "Hello, World!" is a great way to explore the basic set up and syntax o
 
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.actions-tab %}
-1. In the left sidebar, click the workfow you want to run.
+1. In the left sidebar, click the workflow you want to run.
    ![Select say hello job](/assets/images/help/repository/say-hello-job.png)
 1. On the right, click the **Run workflow** drop-down and click **Run workflow**. Optionally, you can enter a custom message into the "Person to greet" input before running the workflow.
    ![Trigger the manual workflow](/assets/images/help/repository/manual-workflow-trigger.png)

content/actions/reference/authentication-in-a-workflow.md

@@ -14,8 +14,6 @@ versions:
 {% data reusables.actions.enterprise-beta %}
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
-Anyone with `write` access to a repository can create, read, and use secrets.
-
 ### About the `GITHUB_TOKEN` secret
 
 {% data variables.product.prodname_dotcom %} automatically creates a `GITHUB_TOKEN` secret to use in your workflow. You can use the `GITHUB_TOKEN` to authenticate in a workflow run.

content/actions/reference/encrypted-secrets.md

@@ -1,6 +1,6 @@
 ---
 title: Encrypted secrets
-intro: Encrypted secrets allow you to store sensitive information in your repository or organization.
+intro: Encrypted secrets allow you to store sensitive information in your organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or repository environments{% else %} or repository{% endif %}.
 product: '{% data reusables.gated-features.actions %}'
 redirect_from:
   - /github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
@@ -12,14 +12,19 @@ versions:
 ---
 
 {% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.environments-beta %}
 {% data reusables.actions.enterprise-github-hosted-runners %}
 
 ### About encrypted secrets
 
-Secrets are encrypted environment variables that you create in a repository or organization. The secrets you create are available to use in {% data variables.product.prodname_actions %} workflows. {% data variables.product.prodname_dotcom %} uses a [libsodium sealed box](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes) to help ensure that secrets are encrypted before they reach {% data variables.product.prodname_dotcom %}, and remain encrypted until you use them in a workflow.
+Secrets are encrypted environment variables that you create in an organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or repository environment{% else %} or repository{% endif %}. The secrets that you create are available to use in {% data variables.product.prodname_actions %} workflows. {% data variables.product.prodname_dotcom %} uses a [libsodium sealed box](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes) to help ensure that secrets are encrypted before they reach {% data variables.product.prodname_dotcom %} and remain encrypted until you use them in a workflow.
 
 {% data reusables.github-actions.secrets-org-level-overview %}
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+For secrets stored at the environment level, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
+{% endif %}
+
 #### Naming your secrets
 
 The following rules apply to secret names:
@@ -27,7 +32,10 @@ The following rules apply to secret names:
 * Secret names can only contain alphanumeric characters (`[a-z]`, `[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed.
 * Secret names must not start with the `GITHUB_` prefix.
 * Secret names must not start with a number.
-* Secret names must be unique at the level they are created at. For example, a secret created at the organization-level must have a unique name at that level, and a secret created at the repository-level must have a unique name in that repository. If an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.
+* Secret names are not case-sensitive.
+* Secret names must be unique at the level they are created at. For example, {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}a secret created at the environment level must have a unique name in that environment, {% endif %}a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level. 
+  
+  If a secret with the same name exists at multiple levels, the secret at the lower level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.{% endif %}
 
 To help ensure that {% data variables.product.prodname_dotcom %} redacts your secret in logs, avoid using structured data as the values of secrets. For example, avoid creating secrets that contain JSON or encoded Git blobs.
 
@@ -43,6 +51,10 @@ You can use and read encrypted secrets in a workflow file if you have access to
 
 {% endwarning %}
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
+{% endif %}
+
 You can also manage secrets using the REST API. For more information, see "[Secrets](/rest/reference/actions#secrets)."
 
 #### Limiting credential permissions
@@ -56,12 +68,27 @@ When generating credentials, we recommend that you grant the minimum permissions
 {% data reusables.repositories.navigate-to-repo %}
 {% data reusables.repositories.sidebar-settings %}
 {% data reusables.github-actions.sidebar-secret %}
-1. Click **Add a new secret**.
+1. Click **New repository secret**.
 1. Type a name for your secret in the **Name** input box.
 1. Enter the value for your secret.
 1. Click **Add secret**.
 
-If your repository can access secrets from the parent organization, then those secrets are also listed on this page.
+If your repository {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}has environment secrets or {% endif %}can access secrets from the parent organization, then those secrets are also listed on this page.
+
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+### Creating encrypted secrets for an environment
+
+{% data reusables.github-actions.permissions-statement-secrets-environment %}
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.github-actions.sidebar-environment %}
+1. Click on the environment that you want to add a secret to.
+1. Under **Environment secrets**, click **Add secret**.
+1. Type a name for your secret in the **Name** input box.
+1. Enter the value for your secret.
+1. Click **Add secret**.
+{% endif %}
 
 ### Creating encrypted secrets for an organization
 
@@ -72,7 +99,7 @@ When creating a secret in an organization, you can use a policy to limit which r
 {% data reusables.organizations.navigate-to-org %}
 {% data reusables.organizations.org_settings %}
 {% data reusables.github-actions.sidebar-secret %}
-1. Click **New secret**.
+1. Click **New organization secret**.
 1. Type a name for your secret in the **Name** input box.
 1. Enter the **Value** for your secret.
 1. From the **Repository access** dropdown list, choose an access policy.
@@ -91,7 +118,7 @@ You can check which access policies are being applied to a secret in your organi
 
 ### Using encrypted secrets in a workflow
 
-With the exception of `GITHUB_TOKEN`, secrets are not passed to the runner when a workflow is triggered from a forked repository.
+{% data reusables.actions.forked-secrets %}
 
 To provide an action with a secret as an input or environment variable, you can use the `secrets` context to access secrets you've created in your repository. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)" and "[Workflow syntax for {% data variables.product.prodname_actions %}](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)."
 
@@ -151,7 +178,7 @@ steps:
 
 ### Limits for secrets
 
-Your workflow can have up to 100 secrets. The names of secret environment variables must be unique in a repository.
+You can store up to 1,000 secrets per organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, 100 secrets per repository, and 100 secrets per environment{% else %} and 100 secrets per repository{% endif %}. A workflow may use up to 100 organization secrets and 100 repository secrets.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} Additionally, a job referencing an environment may use up to 100 environment secrets.{% endif %}
 
 Secrets are limited to 64 KB in size. To use secrets that are larger than 64 KB, you can store encrypted secrets in your repository and save the decryption passphrase as a secret on {% data variables.product.prodname_dotcom %}. For example, you can use `gpg` to encrypt your credentials locally before checking the file in to your repository on {% data variables.product.prodname_dotcom %}. For more information, see the "[gpg manpage](https://www.gnupg.org/gph/de/manual/r1023.html)."
 

content/actions/reference/environment-variables.md

@@ -18,7 +18,7 @@ versions:
 
 {% data variables.product.prodname_dotcom %} sets default environment variables that are available to every step in a workflow run. Environment variables are case-sensitive. Commands run in actions or steps can create, read, and modify environment variables.
 
-To set custom environment variables, you need to specify the variables in the workflow file. You can define environment variables for a step, job, or entire workflow using the [`jobs.<job_id>.steps.env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv), [`jobs.<job_id>.env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idenv), and [`env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) keywords. For more information, see "[Workflow syntax for {% data variables.product.prodname_dotcom %}](/articles/workflow-syntax-for-github-actions/#jobsjob_idstepsenv)."
+To set custom environment variables, you need to specify the variables in the workflow file. You can define environment variables for a step, job, or entire workflow using the [`jobs.<job_id>.steps[*].env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv), [`jobs.<job_id>.env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idenv), and [`env`](/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#env) keywords. For more information, see "[Workflow syntax for {% data variables.product.prodname_dotcom %}](/articles/workflow-syntax-for-github-actions/#jobsjob_idstepsenv)."
 
 ```yaml
 steps:
@@ -51,8 +51,8 @@ We strongly recommend that actions use environment variables to access the files
 | `GITHUB_WORKSPACE` | The {% data variables.product.prodname_dotcom %} workspace directory path. The workspace directory is a copy of your repository if your workflow uses the [actions/checkout](https://github.com/actions/checkout) action. If you don't use the `actions/checkout` action, the directory will be empty. For example, `/home/runner/work/my-repo-name/my-repo-name`. |
 | `GITHUB_SHA` | The commit SHA that triggered the workflow. For example, `ffac537e6cbbf934b08745a378932722df287a53`. |
 | `GITHUB_REF` | The branch or tag ref that triggered the workflow. For example, `refs/heads/feature-branch-1`. If neither a branch or tag is available for the event type, the variable will not exist. |
-| `GITHUB_HEAD_REF` | Only set for forked repositories. The branch of the head repository.
+| `GITHUB_HEAD_REF` | Only set for pull request events. The name of the head branch.
-| `GITHUB_BASE_REF` | Only set for forked repositories. The branch of the base repository.
+| `GITHUB_BASE_REF` | Only set for pull request events. The name of the base branch.
 | `GITHUB_SERVER_URL`| Returns the URL of the {% data variables.product.product_name %} server. For example: `https://{% data variables.product.product_url %}`.
 | `GITHUB_API_URL` | Returns the API URL. For example: `{% data variables.product.api_url_code %}`.
 | `GITHUB_GRAPHQL_URL` | Returns the GraphQL API URL. For example: `{% data variables.product.graphql_url_code %}`.

content/actions/reference/environments.md

@@ -0,0 +1,69 @@
+---
+title: Environments
+intro: You can configure environments with protection rules and secrets. A workflow job can reference an environment to use the environment's protection rules and secrets.
+product: '{% data reusables.gated-features.environments %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=3.1'
+---
+
+{% data reusables.actions.environments-beta %}
+
+### About environments
+
+You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the environment protection rules pass.
+
+{% if currentVersion == "free-pro-team@latest" %}
+Environment protection rules and environment secrets are only available on public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.
+{% endif %}
+
+#### Environment protection rules
+
+Environment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use environment protection rules to require a manual approval or to delay a job.
+
+##### Required reviewers
+
+Use required reviewers to require a specific person or team to approve workflow jobs that reference the environment. You can list up to six users or teams as reviewers. The reviewers must have at least read access to the repository. Only one of the required reviewers needs to approve the job for it to proceed.
+
+For more information on reviewing jobs that reference an environment with required reviewers, see "[Reviewing deployments](/actions/managing-workflow-runs/reviewing-deployments)."
+
+##### Wait timer
+
+Use a wait timer to delay a job for a specific amount of time after the job is initially triggered. The time (in minutes) must be an integer between 0 and 43,200 (30 days).
+
+#### Environment secrets
+
+Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+
+### Creating an environment
+
+{% data reusables.github-actions.permissions-statement-environment %}
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.github-actions.sidebar-environment %}
+1. Click **New environment**.
+1. Enter a name for the environment, then click **Configure environment**. Environment names are not case sensitive. An environment name may not exceed 255 characters and must be unique within the repository.
+1. Configure any environment protection rules or environment secrets.
+
+Running a workflow that references an environment that does not exist will create an environment with the referenced name. The newly created environment will not have any protection rules or secrets configured. Anyone that can edit workflows in the repository can create environments via a workflow file, but only repository admins can configure the environment.
+
+### Referencing an environment
+
+Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. When the job is sent to the runner, the job can access the environment's secrets.
+
+For more information on syntax to reference environments in workflows, see "[Workflow syntax for GitHub Actions](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idenvironment)." For more information on reviewing jobs that reference an environment with required reviewers, see "[Reviewing deployments](/actions/managing-workflow-runs/reviewing-deployments)."
+
+When a workflow references an environment, the environment will appear in the repository's deployments. For more information about viewing current and previous deployments, see "[Viewing deployment history](/developers/overview/viewing-deployment-history)."
+
+### Deleting an environment
+
+{% data reusables.github-actions.permissions-statement-environment %}
+
+Deleting an environment will delete all secrets and protection rules associated with the environment. Any jobs currently waiting because of protection rules from the deleted environment will automatically fail.
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.sidebar-settings %}
+{% data reusables.github-actions.sidebar-environment %}
+1. Next the the environment that you want to delete, click {% octicon "trashcan" aria-label="The trashcan icon" %}.
+2. Click **I understand, delete this environment**.

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

@@ -139,7 +139,7 @@ jobs:
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
 | ------------------ | ------------ | ------------ | ------------------|
-| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | n/a | Last commit on the `GITHUB_REF` branch | Branch that received dispatch |
+| [repository_dispatch](/webhooks/event-payloads/#repository_dispatch) | n/a | Last commit on default branch | Default branch |
 
 {% data reusables.github-actions.branch-requirement %}
 
@@ -311,7 +311,7 @@ Runs your workflow anytime the `issue_comment` event occurs. {% data reusables.d
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
 | --------------------- | -------------- | ------------ | -------------|
-| [`issue_comment`](/rest/reference/activity#issue_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | Last commit on default branch | Default branch |
+| [`issue_comment`](/developers/webhooks-and-events/webhook-events-and-payloads#issue_comment) | - `created`<br/>- `edited`<br/>- `deleted`<br/> | Last commit on default branch | Default branch |
 
 {% data reusables.developer-site.limit_workflow_to_activity_types %}
 
@@ -576,7 +576,13 @@ on:
 
 #### `pull_request_target`
 
-This event is similar to `pull_request`, except that it runs in the context of the base repository of the pull request, rather than in the merge commit. This means that you can more safely make your secrets available to the workflows triggered by the pull request, because only workflows defined in the commit on the base repository are run. For example, this event allows you to create workflows that label and comment on pull requests, based on the contents of the event payload. 
+This event runs in the context of the base of the pull request, rather than in the merge commit as the `pull_request` event does.  This prevents executing unsafe workflow code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows you to do things like create workflows that label and comment on pull requests based on the contents of the event payload.
+
+{% warning %}
+
+**Warning:** The `pull_request_target` event is granted a read/write repository token and can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch, and to help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered.
+
+{% endwarning %}
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
 | --------------------- | -------------- | ------------ | -------------|
@@ -587,7 +593,8 @@ By default, a workflow only runs when a `pull_request_target`'s activity type is
 For example, you can run a workflow when a pull request has been `assigned`, `opened`, `synchronize`, or `reopened`.
 
 ```yaml
-on: pull_request_target
+on:
+  pull_request_target:
     types: [assigned, opened, synchronize, reopened]
 ```
 
@@ -699,6 +706,8 @@ on:
 
 {% data reusables.webhooks.workflow_run_desc %}
 
+{% data reusables.github-actions.branch-requirement %}
+
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
 | --------------------- | -------------- | ------------ | -------------|	
 | [`workflow_run`](/webhooks/event-payloads/#workflow_run) | - n/a | Last commit on default branch | Default branch |	
@@ -723,4 +732,4 @@ on:
 
 {% data reusables.github-actions.actions-do-not-trigger-workflows %} For more information, see "[Authenticating with the GITHUB_TOKEN](/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)."
 
-If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."
+If you would like to trigger a workflow from a workflow run, you can trigger the event using a personal access token. You'll need to create a personal access token and store it as a secret. To minimize your {% data variables.product.prodname_actions %} usage costs, ensure that you don't create recursive or unintended workflow runs. For more information on storing a personal access token as a secret, see "[Creating and storing encrypted secrets](/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)."

content/actions/reference/index.md

@@ -27,11 +27,19 @@ You can configure workflows to run when specific GitHub events occur, at a sched
 
 ### Authentication and secrets
 
-{% data variables.product.prodname_dotcom %} provides a token that you can use to authenticate on behalf of {% data variables.product.prodname_actions %}. You can also store sensitive information as a secret in your organization or repository. {% data variables.product.prodname_dotcom %} encrypts all secrets.
+{% data variables.product.prodname_dotcom %} provides a token that you can use to authenticate on behalf of {% data variables.product.prodname_actions %}. You can also store sensitive information as a secret in your organization{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}, repository, or environments{% else %} or repository{% endif %}. {% data variables.product.prodname_dotcom %} encrypts all secrets.
 
 {% link_in_list /authentication-in-a-workflow %}
 {% link_in_list /encrypted-secrets %}
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+### Environments
+
+Workflow jobs can reference environments that have protection rules or environment-specific secrets.
+
+{% link_in_list /environments %}
+{% endif %}
+
 ### {% data variables.product.prodname_dotcom %}-hosted runners
 
 GitHub offers hosted virtual machines to run workflows. The virtual machine contains an environment with tools, packages, and environment variables for GitHub Actions to use.

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

@@ -301,11 +301,13 @@ steps:
 
 `echo "{path}" >> $GITHUB_PATH`
 
-Prepends a directory to the system `PATH` variable for all subsequent actions in the current job. The currently running action cannot access the new path variable.
+Prepends a directory to the system `PATH` variable and makes it available to all subsequent actions in the current job; the currently running action cannot access the updated path variable. To see the currently defined paths for your job, you can use `echo "$PATH"` in a step or an action.
 
 #### Example
 
+This example demonstrates how to add the user `$HOME/.local/bin` directory to `PATH`:
+
 ``` bash
-echo "/path/to/dir" >> $GITHUB_PATH
+echo "$HOME/.local/bin" >> $GITHUB_PATH
 ```
 {% endif %}

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

@@ -187,7 +187,7 @@ For more information about cron syntax, see "[Events that trigger workflows](/ac
 
 ### `env`
 
-A `map` of environment variables that are available to all jobs and steps in the workflow. You can also set environment variables that are only available to a job or step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps.env`](#jobsjob_idstepsenv).
+A `map` of environment variables that are available to all jobs and steps in the workflow. You can also set environment variables that are only available to a job or step. For more information, see [`jobs.<job_id>.env`](#jobsjob_idenv) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
 
 {% data reusables.repositories.actions-env-var-note %}
 
@@ -223,7 +223,7 @@ defaults:
 
 A workflow run is made up of one or more jobs. Jobs run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the `jobs.<job_id>.needs` keyword.
 
-Each job runs in an environment specified by `runs-on`.
+Each job runs in a runner environment specified by `runs-on`.
 
 You can run an unlimited number of jobs as long as you are within the workflow usage limits. For more information, see "[Usage limits and billing](/actions/reference/usage-limits-billing-and-administration)" for {% data variables.product.prodname_dotcom %}-hosted runners and "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners/#usage-limits)" for self-hosted runner usage limits.
 
@@ -249,9 +249,9 @@ The name of the job displayed on {% data variables.product.prodname_dotcom %}.
 
 ### `jobs.<job_id>.needs`
 
-Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional statement that causes the job to continue.
+Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional expression that causes the job to continue.
 
-#### Example
+#### Example requiring dependent jobs to be successful
 
 ```yaml
 jobs:
@@ -270,6 +270,20 @@ The jobs in this example run sequentially:
 2. `job2`
 3. `job3`
 
+#### Example not requiring dependent jobs to be successful
+
+```yaml
+jobs:
+  job1:
+  job2:
+    needs: job1
+  job3:
+    if: always()
+    needs: [job1, job2]
+```
+
+In this example, `job3` uses the `always()` conditional expression so that it always runs after `job1` and `job2` have completed, regardless of whether they were successful. For more information, see "[Context and expression syntax](/actions/reference/context-and-expression-syntax-for-github-actions#job-status-check-functions)."
+
 ### `jobs.<job_id>.runs-on`
 
 **Required** The type of machine to run the job on. The machine can be either a {% data variables.product.prodname_dotcom %}-hosted runner or a self-hosted runner.
@@ -306,6 +320,39 @@ runs-on: [self-hosted, linux]
 
 For more information, see "[About self-hosted runners](/github/automating-your-workflow-with-github-actions/about-self-hosted-runners)" and "[Using self-hosted runners in a workflow](/github/automating-your-workflow-with-github-actions/using-self-hosted-runners-in-a-workflow)."
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}
+### `jobs.<job_id>.environment`
+
+The environment that the job references. All environment protection rules must pass before a job referencing the environment is sent to a runner. For more information, see "[Environments](/actions/reference/environments)."
+
+You can provide the environment as only the environment `name`, or as an environment object with the `name` and `url`. The URL maps to `environment_url` in the deployments API. For more information about the deployments API, see "[Deployments](/rest/reference/repos#deployments)."
+
+##### Example using a single environment name
+
+```yaml
+environment: staging_environment
+```
+
+##### Example using environment name and URL
+
+```yaml
+environment:
+  name: production_environment
+  url: https://github.com
+```
+
+The URL can be an expression and can use any context except for the `secrets` context. For more information about expressions, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
+
+#### Example
+{% raw %}
+```yaml
+environment:
+  name: production_environment
+  url: ${{ steps.step_name.outputs.url_output }}
+```
+{% endraw %}
+{% endif %}
+
 ### `jobs.<job_id>.outputs`
 
 A `map` of outputs for a job. Job outputs are available to all downstream jobs that depend on this job. For more information on defining job dependencies, see [`jobs.<job_id>.needs`](#jobsjob_idneeds).
@@ -340,7 +387,7 @@ jobs:
 
 ### `jobs.<job_id>.env`
 
-A `map` of environment variables that are available to all steps in the job. You can also set environment variables for the entire workflow or an individual step. For more information, see [`env`](#env) and [`jobs.<job_id>.steps.env`](#jobsjob_idstepsenv).
+A `map` of environment variables that are available to all steps in the job. You can also set environment variables for the entire workflow or an individual step. For more information, see [`env`](#env) and [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv).
 
 {% data reusables.repositories.actions-env-var-note %}
 
@@ -415,11 +462,11 @@ jobs:
 ```
 {% endraw %}
 
-### `jobs.<job_id>.steps.id`
+### `jobs.<job_id>.steps[*].id`
 
 A unique identifier for the step. You can use the `id` to reference the step in contexts. For more information, see "[Context and expression syntax for {% data variables.product.prodname_actions %}](/actions/reference/context-and-expression-syntax-for-github-actions)."
 
-### `jobs.<job_id>.steps.if`
+### `jobs.<job_id>.steps[*].if`
 
 You can use the `if` conditional to prevent a step from running unless a condition is met. You can use any supported context and expression to create a conditional.
 
@@ -449,11 +496,11 @@ steps:
     uses: actions/heroku@1.0.0
 ```
 
-### `jobs.<job_id>.steps.name`
+### `jobs.<job_id>.steps[*].name`
 
 A name for your step to display on {% data variables.product.prodname_dotcom %}.
 
-### `jobs.<job_id>.steps.uses`
+### `jobs.<job_id>.steps[*].uses`
 
 Selects an action to run as part of a step in your job. An action is a reusable unit of code. You can use an action defined in the same repository as the workflow, a public repository, or in a [published Docker container image](https://hub.docker.com/).
 
@@ -556,7 +603,7 @@ jobs:
         uses: docker://gcr.io/cloud-builders/gradle
 ```
 
-### `jobs.<job_id>.steps.run`
+### `jobs.<job_id>.steps[*].run`
 
 Runs command-line programs using the operating system's shell. If you do not provide a `name`, the step name will default to the text specified in the `run` command.
 
@@ -661,7 +708,7 @@ For built-in shell keywords, we provide the following defaults that are executed
   - 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 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`
+### `jobs.<job_id>.steps[*].with`
 
 A `map` of the input parameters defined by the action. Each input parameter is a key/value pair. Input parameters are set as environment variables. The variable is prefixed with `INPUT_` and converted to upper case.
 
@@ -681,7 +728,7 @@ jobs:
           last_name: Octocat      
 ```
 
-### `jobs.<job_id>.steps.with.args`
+### `jobs.<job_id>.steps[*].with.args`
 
 A `string` that defines the inputs for a Docker container. {% data variables.product.prodname_dotcom %} passes the `args` to the container's `ENTRYPOINT` when the container starts up. An `array of strings` is not supported by this parameter.
 
@@ -704,7 +751,7 @@ The `args` are used in place of the `CMD` instruction in a `Dockerfile`. If you
 1. Use defaults that allow using the action without specifying any `args`.
 1. If the action exposes a `--help` flag, or something similar, use that as the default to make your action self-documenting.
 
-### `jobs.<job_id>.steps.with.entrypoint`
+### `jobs.<job_id>.steps[*].with.entrypoint`
 
 Overrides the Docker `ENTRYPOINT` in the `Dockerfile`, or sets it if one wasn't already specified. Unlike the Docker `ENTRYPOINT` instruction which has a shell and exec form, `entrypoint` keyword accepts only a single string defining the executable to be run.
 
@@ -720,7 +767,7 @@ steps:
 
 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`
+### `jobs.<job_id>.steps[*].env`
 
 Sets environment variables for steps to use in the runner environment. You can also set environment variables for the entire workflow or a job. For more information, see [`env`](#env) and [`jobs.<job_id>.env`](#jobsjob_idenv).
 
@@ -741,11 +788,11 @@ steps:
 ```
 {% endraw %}
 
-### `jobs.<job_id>.steps.continue-on-error`
+### `jobs.<job_id>.steps[*].continue-on-error`
 
 Prevents a job from failing when a step fails. Set to `true` to allow a job to pass when this step fails.
 
-### `jobs.<job_id>.steps.timeout-minutes`
+### `jobs.<job_id>.steps[*].timeout-minutes`
 
 The maximum number of minutes to run the step before killing the process.
 
@@ -755,7 +802,7 @@ The maximum number of minutes to let a job run before {% data variables.product.
 
 ### `jobs.<job_id>.strategy`
 
-A strategy creates a build matrix for your jobs. You can define different variations of an environment to run each job in.
+A strategy creates a build matrix for your jobs. You can define different variations to run each job in.
 
 ### `jobs.<job_id>.strategy.matrix`
 
@@ -1102,7 +1149,7 @@ You can use special characters in path, branch, and tag filters.
 - `**`: Matches zero or more of any character.
 - `?`: Matches zero or one single character. For example, `Octoc?t` matches `Octocat`.
 - `+`: Matches one or more of the preceding character.
-- `[]` Matches one character listed in the brackets or included in ranges. Ranges can only include `a-z`, `A-Z`, and `0-9`. For example, the range`[0-9a-f]` matches any digits or lowercase letter. For example, `[CB]at` matches `Cat` or `Bat` and `[1-2]00` matches `100` and `200`.
+- `[]` Matches one character listed in the brackets or included in ranges. Ranges can only include `a-z`, `A-Z`, and `0-9`. For example, the range`[0-9a-z]` matches any digit or lowercase letter. For example, `[CB]at` matches `Cat` or `Bat` and `[1-2]00` matches `100` and `200`.
 - `!`: At the start of a pattern makes it negate previous positive patterns. It has no special meaning if not the first character.
 
 The characters `*`, `[`, and `!` are special characters in YAML. If you start a pattern with `*`, `[`, or `!`, you must enclose the pattern in quotes.
@@ -1122,14 +1169,14 @@ For more information about branch, tag, and path filter syntax, see "[`on.<push|
 
 | Pattern | Description | Example matches |
 |---------|------------------------|---------|
-| `feature/*` | The `*` wildcard matches any character, but does not match slash (`/`). |  -`feature/my-branch`<br/>-`feature/your-branch` |
+| `feature/*` | The `*` wildcard matches any character, but does not match slash (`/`). |  `feature/my-branch`<br/><br/>`feature/your-branch` |
-| `feature/**` | The `**` wildcard matches any character including slash (`/`) in branch and tag names. | -`feature/beta-a/my-branch`<br/>-`feature/your-branch`<br/>-`feature/mona/the/octocat` |
+| `feature/**` | The `**` wildcard matches any character including slash (`/`) in branch and tag names. | `feature/beta-a/my-branch`<br/><br/>`feature/your-branch`<br/><br/>`feature/mona/the/octocat` |
-| -`main`<br/>-`releases/mona-the-octcat` | Matches the exact name of a branch or tag name. | -`main`<br/>-`releases/mona-the-octocat` |
+| `main`<br/><br/>`releases/mona-the-octcat` | Matches the exact name of a branch or tag name. | `main`<br/><br/>`releases/mona-the-octocat` |
-| `'*'` | Matches all branch and tag names that don't contain a slash (`/`). The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes. | -`main`<br/>-`releases` |
+| `'*'` | Matches all branch and tag names that don't contain a slash (`/`). The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes. | `main`<br/><br/>`releases` |
-| `'**'` | Matches all branch and tag names. This is the default behavior when you don't use a `branches` or `tags` filter. | -`all/the/branches`<br/>-`every/tag` |
+| `'**'` | Matches all branch and tag names. This is the default behavior when you don't use a `branches` or `tags` filter. | `all/the/branches`<br/><br/>`every/tag` |
-| `'*feature'` | The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes. | -`mona-feature`<br/>-`feature`<br/>-`ver-10-feature` |
+| `'*feature'` | The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes. | `mona-feature`<br/><br/>`feature`<br/><br/>`ver-10-feature` |
-| `v2*` | Matches branch and tag names that start with `v2`. | -`v2`<br/>-`v2.0`<br/>-`v2.9` |
+| `v2*` | Matches branch and tag names that start with `v2`. | `v2`<br/><br/>`v2.0`<br/><br/>`v2.9` |
-| `v[12].[0-9]+.[0-9]+` | Matches all semantic versioning tags with major version 1 or 2 | -`v1.10.1`<br/>-`v2.0.0` |
+| `v[12].[0-9]+.[0-9]+` | Matches all semantic versioning tags with major version 1 or 2 | `v1.10.1`<br/><br/>`v2.0.0` |
 
 #### Patterns to match file paths
 
@@ -1137,18 +1184,18 @@ Path patterns must match the whole path, and start from the repository's root.
 
 | Pattern | Description of matches | Example matches |
 |---------|------------------------|-----------------|
-| `'*'` | The `*` wildcard matches any character, but does not match slash (`/`). The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes. | -`README.md`<br/>-`server.rb` |
+| `'*'` | The `*` wildcard matches any character, but does not match slash (`/`). The `*` character is a special character in YAML. When you start a pattern with `*`, you must use quotes. | `README.md`<br/><br/>`server.rb` |
-| `'*.jsx?'` | The `?` character matches zero or one of the preceding character. | -`page.js`<br/>-`page.jsx` |
+| `'*.jsx?'` | The `?` character matches zero or one of the preceding character. | `page.js`<br/><br/>`page.jsx` |
-| `'**'` | The `**` wildcard matches any character including slash (`/`). This is the default behavior when you don't use a `path` filter. | -`all/the/files.md` |
+| `'**'` | The `**` wildcard matches any character including slash (`/`). This is the default behavior when you don't use a `path` filter. | `all/the/files.md` |
-| `'*.js'` | The `*` wildcard matches any character, but does not match slash (`/`). Matches all `.js` files at the root of the repository. | -`app.js`<br/>-`index.js`
+| `'*.js'` | The `*` wildcard matches any character, but does not match slash (`/`). Matches all `.js` files at the root of the repository. | `app.js`<br/><br/>`index.js`
-| `'**.js'` | Matches all `.js` files in the repository. | -`index.js`<br/>-`js/index.js`<br/>-`src/js/app.js` |
+| `'**.js'` | Matches all `.js` files in the repository. | `index.js`<br/><br/>`js/index.js`<br/><br/>`src/js/app.js` |
-| `docs/*`  | All files within the root of the `docs` directory, at the root of the repository. | -`docs/README.md`<br/>-`docs/file.txt` |
+| `docs/*`  | All files within the root of the `docs` directory, at the root of the repository. | `docs/README.md`<br/><br/>`docs/file.txt` |
-| `docs/**` | Any files in the `/docs` directory at the root of the repository. | -`docs/README.md`<br/>-`docs/mona/octocat.txt` |
+| `docs/**` | Any files in the `/docs` directory at the root of the repository. | `docs/README.md`<br/><br/>`docs/mona/octocat.txt` |
-| `docs/**/*.md` | A file with a `.md` suffix anywhere in the `docs` directory. | -`docs/README.md`<br/>-`docs/mona/hello-world.md`<br/>-`docs/a/markdown/file.md`
+| `docs/**/*.md` | A file with a `.md` suffix anywhere in the `docs` directory. | `docs/README.md`<br/><br/>`docs/mona/hello-world.md`<br/><br/>`docs/a/markdown/file.md`
-| `'**/docs/**'`   | Any files in a `docs` directory anywhere in the repository. | -`/docs/hello.md`<br/>-`dir/docs/my-file.txt`<br/>-`space/docs/plan/space.doc`
+| `'**/docs/**'`   | Any files in a `docs` directory anywhere in the repository. | `/docs/hello.md`<br/><br/>`dir/docs/my-file.txt`<br/><br/>`space/docs/plan/space.doc`
-| `'**/README.md'` | A README.md file anywhere in the repository. | -`README.md`<br/>-`js/README.md`
+| `'**/README.md'` | A README.md file anywhere in the repository. | `README.md`<br/><br/>`js/README.md`
-| `'**/*src/**'` | Any file in a folder with a `src` suffix anywhere in the repository. | -`a/src/app.js`<br/>-`my-src/code/js/app.js`
+| `'**/*src/**'` | Any file in a folder with a `src` suffix anywhere in the repository. | `a/src/app.js`<br/><br/>`my-src/code/js/app.js`
-| `'**/*-post.md'` | A file with the suffix `-post.md` anywhere in the repository. | -`my-post.md`<br/>-`path/their-post.md` |
+| `'**/*-post.md'` | A file with the suffix `-post.md` anywhere in the repository. | `my-post.md`<br/><br/>`path/their-post.md` |
-| `'**/migrate-*.sql'` | A file with the prefix `migrate-` and suffix `.sql` anywhere in the repository. | -`migrate-10909.sql`<br/>-`db/migrate-v1.0.sql`<br/>-`db/sept/migrate-v1.sql` |
+| `'**/migrate-*.sql'` | A file with the prefix `migrate-` and suffix `.sql` anywhere in the repository. | `migrate-10909.sql`<br/><br/>`db/migrate-v1.0.sql`<br/><br/>`db/sept/migrate-v1.sql` |
-| -`*.md`<br/>-`!README.md` | Using an exclamation mark (`!`) in front of a pattern negates it. When a file matches a pattern and also matches a negative pattern defined later in the file, the file will not be included. | -`hello.md`<br/>_Does not match_<br/>-`README.md`<br/>-`docs/hello.md` |
+| `*.md`<br/><br/>`!README.md` | Using an exclamation mark (`!`) in front of a pattern negates it. When a file matches a pattern and also matches a negative pattern defined later in the file, the file will not be included. | `hello.md`<br/><br/>_Does not match_<br/><br/>`README.md`<br/><br/>`docs/hello.md` |
-| -`*.md`<br/>-`!README.md`<br/>-`README*` | Patterns are checked sequentially. A pattern that negates a previous pattern will re-include file paths. | -`hello.md`<br/>-`README.md`<br/>-`README.doc`|
+| `*.md`<br/><br/>`!README.md`<br/><br/>`README*` | Patterns are checked sequentially. A pattern that negates a previous pattern will re-include file paths. | `hello.md`<br/><br/>`README.md`<br/><br/>`README.doc`|

content/admin/authentication/using-saml.md

@@ -46,7 +46,7 @@ A mapping is created between the `NameID` and the {% data variables.product.prod
 
 ### SAML metadata
 
-Your {% data variables.product.prodname_ghe_server %} instances's service provider metadata is available at `http(s)://[hostname]/saml/metadata`.
+Your {% data variables.product.prodname_ghe_server %} instance's service provider metadata is available at `http(s)://[hostname]/saml/metadata`.
 
 To configure your identity provider manually, the Assertion Consumer Service (ACS) URL is `http(s)://[hostname]/saml/consume`. It uses the `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST` binding.
 

content/admin/configuration/configuring-email-for-notifications.md

@@ -18,6 +18,7 @@ Notification emails are sent if there is activity on a repository a user is watc
 Your dedicated technical account manager in {% data variables.contact.github_support %} can configure email for notifications to be sent through your SMTP server. Make sure you include the following details in your support request.
 
 - Your SMTP server address
+- Login information to authenticate to the server: username and password
 - The port your SMTP server uses to send email
 - The domain name that your SMTP server will send with a HELO response, if any
 - The type of encryption used by your SMTP server

content/admin/enterprise-support/about-github-enterprise-support.md

@@ -93,7 +93,7 @@ For urgent issues, we can help you in English 24 hours per day, 7 days per week,
 | Day after Thanksgiving      | Fourth Friday in November   |
 | Christmas Eve               | December 24                 |
 | Christmas Day               | December 25                 |
-| Day after Christmas         | December 26                 |
+| Day after Christmas         | December 28                 |
 | New Year's Eve              | December 31                 |
 
 #### Holidays in Japan

content/admin/enterprise-support/about-support-for-advanced-security.md

@@ -44,7 +44,7 @@ We offer support for {% data variables.product.prodname_advanced_security %} in
 
 {% data variables.contact.enterprise_support %} observes these U.S. holidays.
 
-| U.S. holiday                | Date observed in 2018       |
+| U.S. holiday                | Date observed       |
 | ---                         | ---                         |
 | New Year's Day              | January 1                   |
 | Martin Luther King, Jr. Day | Third Monday in January     |
@@ -57,7 +57,7 @@ We offer support for {% data variables.product.prodname_advanced_security %} in
 | Day after Thanksgiving      | Fourth Friday in November   |
 | Christmas Eve               | December 24                 |
 | Christmas Day               | December 25                 |
-| Day after Christmas         | December 26                 |
+| Day after Christmas         | December 28                 |
 | New Year's Eve              | December 31                 |
 
 ### Installing {% data variables.product.prodname_advanced_security %} updates

content/admin/index.md

@@ -28,3 +28,5 @@ versions:
 {% link_with_intro /packages %}
 
 {% link_with_intro /enterprise-support %}
+
+{% link_with_intro /release-notes %}

content/admin/overview/about-enterprise-accounts.md

@@ -18,7 +18,11 @@ An enterprise account allows you to manage multiple organizations{% if enterpris
 - Security {% if enterpriseServerVersions contains currentVersion %}(single sign-on, two factor authentication)
 - Requests {% if enterpriseServerVersions contains currentVersion %}and support bundle sharing {% endif %}with {% data variables.contact.enterprise_support %}{% endif %}
 
-{% if enterpriseServerVersions contains currentVersion %}{% data reusables.enterprise-accounts.enterprise-accounts-billing %} For more information about managing your {% data variables.product.prodname_ghe_cloud %} subscription, see "[Viewing the subscription and usage for your enterprise account](/articles/viewing-the-subscription-and-usage-for-your-enterprise-account)." {% endif %}For more information about managing your {% data variables.product.product_name %} billing settings, see "[Managing billing for your enterprise](/admin/overview/managing-billing-for-your-enterprise)."
+{% if enterpriseServerVersions contains currentVersion %}{% data reusables.enterprise-accounts.enterprise-accounts-billing %} For more information about the management of your {% data variables.product.prodname_ghe_cloud %} subscription, see "[Viewing the subscription and usage for your enterprise account](/articles/viewing-the-subscription-and-usage-for-your-enterprise-account)." {% endif %}For more information about managing your {% data variables.product.product_name %} billing settings, see "[Managing billing for your enterprise](/admin/overview/managing-billing-for-your-enterprise)."
+
+For more information about the management of users, organizations, data, and policies for {% data variables.product.product_location %}, see "[Managing users, organizations, and repositories](/admin/user-management)" and "[Setting policies for your enterprise](/admin/policies)."
+
+For more information about the management of enterprise accounts using the GraphQL API, see "[Enterprise accounts](/graphql/guides/managing-enterprise-accounts)."
 
 {% if enterpriseServerVersions contains currentVersion %}
 

content/desktop/installing-and-configuring-github-desktop/keyboard-shortcuts.md

@@ -51,6 +51,7 @@ GitHub Desktop keyboard shortcuts on macOS
 |<kbd>⌘</kbd><kbd>2</kbd> | Show your commit history
 |<kbd>⌘</kbd><kbd>B</kbd> | Show all your branches
 |<kbd>⌘</kbd><kbd>G</kbd> | Go to the commit summary field
+|<kbd>⌘</kbd><kbd>Enter</kbd> | Commit changes when summary or description field is active
 |<kbd>space</kbd>| Select or deselect all highlighted files
 |<kbd>⇧</kbd><kbd>⌘</kbd><kbd>N</kbd> | Create a new branch
 |<kbd>⇧</kbd><kbd>⌘</kbd><kbd>R</kbd> | Rename the current branch
@@ -104,6 +105,7 @@ GitHub Desktop keyboard shortcuts on Windows
 |<kbd>Ctrl</kbd><kbd>2</kbd> | Show your commit history
 |<kbd>Ctrl</kbd><kbd>B</kbd> | Show all your branches
 |<kbd>Ctrl</kbd><kbd>G</kbd> | Go to the commit summary field
+|<kbd>Ctrl</kbd><kbd>Enter</kbd> | Commit changes when summary or description field is active
 |<kbd>space</kbd>| Select or deselect all highlighted files
 |<kbd>Ctrl</kbd><kbd>Shift</kbd><kbd>N</kbd> | Create a new branch
 |<kbd>Ctrl</kbd><kbd>Shift</kbd><kbd>R</kbd> | Rename the current branch

content/developers/apps/authorizing-oauth-apps.md

@@ -272,7 +272,9 @@ The optional `redirect_uri` parameter can also be used for localhost URLs. If th
 
 For the `http://localhost/path` callback URL, you can use this `redirect_uri`:
 
+```
 http://localhost:1234/path
+```
 
 ### Creating multiple tokens for OAuth Apps
 

content/developers/apps/creating-a-github-app-using-url-parameters.md

@@ -79,8 +79,8 @@ Permission | Description
 [`single_file`](/rest/reference/permissions-required-for-github-apps/#permission-on-single-file) | Grants access to the [Contents API](/rest/reference/repos#contents). Can be one of: `none`, `read`, or `write`.
 [`starring`](/rest/reference/permissions-required-for-github-apps/#permission-on-starring) | Grants access to the [Starring API](/rest/reference/activity#starring). Can be one of: `none`, `read`, or `write`.
 [`statuses`](/rest/reference/permissions-required-for-github-apps/#permission-on-statuses) | Grants access to the [Statuses API](/rest/reference/repos#statuses). Can be one of: `none`, `read`, or `write`.
-[`team_discussions`](/rest/reference/permissions-required-for-github-apps/#permission-on-team-discussions) | Grants access to the [Team Discussions API](/rest/reference/teams#discussions) and the [Team Discussion Comments API](/rest/reference/teams#discussion-comments). Can be one of: `none`, `read`, or `write`.
+[`team_discussions`](/rest/reference/permissions-required-for-github-apps/#permission-on-team-discussions) | Grants access to the [Team Discussions API](/rest/reference/teams#discussions) and the [Team Discussion Comments API](/rest/reference/teams#discussion-comments). Can be one of: `none`, `read`, or `write`.{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@1.19" %}
-`vulnerability_alerts`| Grants access to receive security alerts for vulnerable dependencies in a repository. See "[About security alerts for vulnerable dependencies](/articles/about-security-alerts-for-vulnerable-dependencies)" to learn more. Can be one of: `none` or `read`.
+`vulnerability_alerts`| Grants access to receive security alerts for vulnerable dependencies in a repository. See "[About security alerts for vulnerable dependencies](/articles/about-security-alerts-for-vulnerable-dependencies)" to learn more. Can be one of: `none` or `read`.{% endif %}
 `watching` | Grants access to list and change repositories a user is subscribed to. Can be one of: `none`, `read`, or `write`.
 
 ### {% data variables.product.prodname_github_app %} webhook events

content/developers/apps/differences-between-github-apps-and-oauth-apps.md

@@ -85,7 +85,7 @@ Unlike OAuth apps, GitHub Apps have targeted permissions that allow them to requ
 
 | GitHub Apps | OAuth Apps |
 | ----- | ----------- |
-| By default, GitHub Apps have a single webhook that receives the events they are configured to receive for every repository they have access to. | OAuth Apps request the webhook scope to create a repository webhook for each repository they needs to receive events from. |
+| By default, GitHub Apps have a single webhook that receives the events they are configured to receive for every repository they have access to. | OAuth Apps request the webhook scope to create a repository webhook for each repository they need to receive events from. |
 | GitHub Apps receive certain organization-level events with the organization member's permission. | OAuth Apps request the organization webhook scope to create an organization webhook for each organization they need to receive organization-level events from. |
 
 ### Git access

content/developers/apps/identifying-and-authorizing-users-for-github-apps.md

@@ -67,7 +67,7 @@ If the user accepts your request, GitHub redirects back to your site with a temp
 
 {% endnote %}
 
-Exchange this `code` for an access token. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" or currentVersion == "github-ae@latest" %} When expiring tokens are enabled, the access token expires in 8 hours and the refresh token expires in 6 months. Every time you refresh the token, you get a new refresh token. For more information, see "[Refreshing user-to-server access tokens](/developers/apps/refreshing-user-to-server-access-tokens)."
+Exchange this `code` for an access token. {% if currentVersion == "free-pro-team@latest" %} When expiring tokens are enabled, the access token expires in 8 hours and the refresh token expires in 6 months. Every time you refresh the token, you get a new refresh token. For more information, see "[Refreshing user-to-server access tokens](/developers/apps/refreshing-user-to-server-access-tokens)."
 
 Expiring user tokens are currently part of the user-to-server token expiration beta and subject to change. To opt-in to the user-to-server token expiration beta feature, see "[Activating beta features for apps](/developers/apps/activating-beta-features-for-apps)."{% endif %}
 

content/developers/apps/suspending-a-github-app-installation.md

@@ -7,13 +7,11 @@ versions:
   free-pro-team: '*'
 ---
 
-{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
 {% note %}
 
 **Note:** {% data reusables.pre-release-program.suspend-installation-beta %}
 
 {% endnote %}
-{% endif %}
 
 ### Suspending a GitHub App
 

content/developers/apps/using-content-attachments.md

@@ -166,7 +166,7 @@ To create a Probot App, follow these steps:
     }
     ```
 
-4. [Run the GitHub App locally](https://probot.github.io/docs/development/#running-the-app-locally). Navigate to [localhost:3000](http://localhost:3000), and click the **Register GitHub App** button:
+4. [Run the GitHub App locally](https://probot.github.io/docs/development/#running-the-app-locally). Navigate to `http://localhost:3000`, and click the **Register GitHub App** button:
 
    ![Register a Probot GitHub App](/assets/images/github-apps/github_apps_probot-registration.png)
 

content/developers/github-marketplace/creating-apps-for-github-marketplace.md

@@ -4,6 +4,5 @@ intro: 'You can list free and paid tools for developers to use in {% data variab
 mapTopic: true
 versions:
   free-pro-team: '*'
-  enterprise-server: '*'
 ---
 

content/developers/github-marketplace/pricing-plans-for-github-marketplace-apps.md

@@ -48,7 +48,7 @@ Customers can start a free trial for any paid plan on a Marketplace listing that
 
 Free trials have a fixed length of 14 days. Customers are notified 4 days before the end of their trial period (on day 11 of the free trial) that their plan will be upgraded. At the end of a free trial, customers will be auto-enrolled into the plan they are trialing if they do not cancel.
 
-For more information, see: "[Handling new purchases and free trials](/developers/github-marketplace/integrating-with-the-github-marketplace-api/handling-new-purchases-and-free-trials/)."
+For more information, see: "[Handling new purchases and free trials](/developers/github-marketplace/handling-new-purchases-and-free-trials/)."
 
 {% note %}
 

content/developers/github-marketplace/receiving-payment-for-app-purchases.md

@@ -13,8 +13,14 @@ versions:
 
 
 
-After your {% data variables.product.prodname_marketplace %} listing is created and approved, you'll provide payment details to {% data variables.product.product_name %} as part of the onboarding process.
+After your {% data variables.product.prodname_marketplace %} listing for an app with a paid plan is created and approved, you'll provide payment details to {% data variables.product.product_name %} as part of the financial onboarding process.
 
-Once your revenue reaches a minimum of $500 U.S. Dollars for the month, you'll receive an electronic payment from {% data variables.product.product_name %} for 75% of the sales price.
+Once your revenue reaches a minimum of $500 US dollars for the month, you'll receive an electronic payment from {% data variables.product.company_short %}. This will be the income from marketplace transactions minus the amount charged by {% data variables.product.company_short %} to cover their running costs.
 
-{% data reusables.apps.marketplace_revenue_share %}
+For transactions made before January 1, 2021, {% data variables.product.company_short %} retains 25% of transaction income. For transactions made after that date, only 5% is retained by {% data variables.product.company_short %}. This change will be reflected in payments received from the end of January 2021 onward.
+
+{% note %}
+
+**Note:** For details of the current pricing and payment terms, see "[{% data variables.product.prodname_marketplace %} developer agreement](/github/site-policy/github-marketplace-developer-agreement)."
+
+{% endnote %}

content/developers/github-marketplace/requirements-for-listing-an-app.md

@@ -53,7 +53,7 @@ In addition to the requirements for all apps above, each app that you offer as a
 - {% data variables.product.prodname_github_app %}s should have a minimum of 100 installations.
 - {% data variables.product.prodname_oauth_app %}s should have a minimum of 200 users.
 - All paid apps must handle {% data variables.product.prodname_marketplace %} purchase events for new purchases, upgrades, downgrades, cancellations, and free trials. For more information, see "[Billing requirements for paid apps](#billing-requirements-for-paid-apps)" below.
-- Publishing organizations must have a verified domain and must enable two-factor authentication. For more information, see "[Requiring two-factor authentication in your organization](/github/setting-up-and-managing-organizations-and-teams/requiring-two-factor-authentication-in-your-organization.")
+- Publishing organizations must have a verified domain and must enable two-factor authentication. For more information, see "[Requiring two-factor authentication in your organization](/github/setting-up-and-managing-organizations-and-teams/requiring-two-factor-authentication-in-your-organization)."
 
 When you are ready to publish the app on {% data variables.product.prodname_marketplace %} you must request verification for the listing.
 

content/developers/github-marketplace/viewing-transactions-for-your-listing.md

@@ -1,6 +1,6 @@
 ---
 title: Viewing transactions for your listing
-intro: 'The {% data variables.product.prodname_marketplace %} transactions page allows you to download and view all transactions for your {% data variables.product.prodname_marketplace %} listing. You can view transations for the past day (24 hours), week, month, or for the entire duration of time that your {% data variables.product.prodname_github_app %} has been listed.'
+intro: 'The {% data variables.product.prodname_marketplace %} transactions page allows you to download and view all transactions for your {% data variables.product.prodname_marketplace %} listing. You can view transactions for the past day (24 hours), week, month, or for the entire duration of time that your {% data variables.product.prodname_github_app %} has been listed.'
 redirect_from:
   - /marketplace/github-marketplace-transactions
 versions:

content/developers/overview/index.md

@@ -11,6 +11,7 @@ versions:
 
 {% link_in_list /about-githubs-apis %}
 {% link_in_list /managing-deploy-keys %}
+{% link_in_list /viewing-deployment-history %}
 {% link_in_list /using-ssh-agent-forwarding %}
 {% link_in_list /secret-scanning %}
 {% link_in_list /replacing-github-services %}

content/developers/overview/managing-deploy-keys.md

@@ -44,7 +44,9 @@ If you don't want to use SSH keys, you can use [HTTPS with OAuth tokens][git-aut
 * Users don't have to change their local SSH settings.
 * Multiple tokens (one for each user) are not needed; one token per server is enough.
 * A token can be revoked at any time, turning it essentially into a one-use password.
+{% if enterpriseServerVersions contains currentVersion %}
 * Generating new tokens can be easily scripted using [the OAuth API](/rest/reference/oauth-authorizations#create-a-new-authorization).
+{% endif %}
 
 ##### Cons
 

content/developers/overview/viewing-deployment-history.md

@@ -0,0 +1,20 @@
+---
+title: Viewing deployment history
+intro: View current and previous deployments for your repository.
+versions:
+  free-pro-team: '*'
+  enterprise-server: '*'
+  github-ae: '*'
+---
+
+{% data reusables.actions.environments-beta %}
+
+You can deliver deployments through {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}{% data variables.product.prodname_actions %} and environments or with {% endif %}the REST API and third party apps. {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %}For more information about {% data variables.product.prodname_actions %}, see "[{% data variables.product.prodname_actions %}](/actions)." {% endif %}For more information about deployments with the REST API, see "[Repositories](/rest/reference/repos#deployments)."
+
+To view current and past deployments, click **Environments** on the home page of your repository. ![Environments](/assets/images/environments-sidebar.png)
+
+The deployments page displays the last active deployment of each environment for your repository. If the deployment includes an environment URL, a "View deployment" button that links to the URL is shown next to the deployment.
+
+The activity log shows the deployment history for your environments. By default, only the most recent deployment for an environment has an `Active` status; all previously active deployments have an `Inactive` status. For more information on automatic inactivation of deployments, see "[Inactive deployments](/rest/reference/repos#inactive-deployments)."
+
+You can also use the REST API to get information about deployments. For more information, see "[Repositories](/rest/reference/repos#deployments)."

content/developers/webhooks-and-events/issue-event-types.md

@@ -91,7 +91,7 @@ The base reference branch of the pull request changed.
 |:----------|:----------------:|:-----------------:|
 | <ul><li>Pull requests</li></ul> | **X** | |
 
- ### Event object properties
+#### Event object properties
 
 {% data reusables.issue-events.issue-event-common-properties %}
 

content/developers/webhooks-and-events/securing-your-webhooks.md

@@ -72,7 +72,7 @@ end
 {% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.22" or currentVersion == "github-ae@latest" %}
 def verify_signature(payload_body)
   signature = 'sha256=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha256'), ENV['SECRET_TOKEN'], payload_body)
-  return halt 500, "Signatures didn't match!" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_HUB_SIGNATURE_2'])
+  return halt 500, "Signatures didn't match!" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_HUB_SIGNATURE_256'])
 end{% elsif currentVersion ver_lt "enterprise-server@2.23" %}
 def verify_signature(payload_body)
   signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body)

content/developers/webhooks-and-events/webhook-events-and-payloads.md

@@ -430,7 +430,7 @@ Key | Type | Description
 
 {% endnote %}
 
-{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" or currentVersion == "github-ae@latest" %}
+{% if currentVersion == "free-pro-team@latest" %}
 {% note %}
 
 **Note:** {% data reusables.pre-release-program.suspend-installation-beta %} For more information, see "[Suspending a {% data variables.product.prodname_github_app %} installation](/apps/managing-github-apps/suspending-a-github-app-installation/)."
@@ -715,7 +715,7 @@ Key | Type | Description
 
 ### package
 
-Activity related to {% data variables.product.prodname_registry %}. {% data reusables.webhooks.action_type_desc %} For more information, see the "[blocking organization users](/rest/reference/orgs#blocking)" REST API. For more information, see "[Managing packages with {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages)" to learn more about {% data variables.product.prodname_registry %}.
+Activity related to {% data variables.product.prodname_registry %}. {% data reusables.webhooks.action_type_desc %} For more information, see "[Managing packages with {% data variables.product.prodname_registry %}](/github/managing-packages-with-github-packages)" to learn more about {% data variables.product.prodname_registry %}.
 
 #### Availability
 
@@ -1124,9 +1124,11 @@ Key | Type | Description
 {{ webhookPayloadsForCurrentVersion.secret_scanning_alert.reopened }}
 {% endif %}
 
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@1.19" %}
 ### security_advisory
 
 Activity related to a security advisory. A security advisory provides information about security-related vulnerabilities in software on GitHub. The security advisory dataset also powers the GitHub security alerts, see "[About security alerts for vulnerable dependencies](/articles/about-security-alerts-for-vulnerable-dependencies/)."
+{% endif %}
 
 #### Availability
 

content/education/manage-coursework-with-github-classroom/leave-feedback-with-pull-requests.md

@@ -30,4 +30,4 @@ To create and access the feedback pull request, you must enable the feedback pul
 
 ### Further reading
 
-- "[Integrate {% data variables.product.prodname_classroom %} with an IDE](http://localhost:4000/en/free-pro-team@latest/education/manage-coursework-with-github-classroom/integrate-github-classroom-with-an-ide)"
+- "[Integrate {% data variables.product.prodname_classroom %} with an IDE](/education/manage-coursework-with-github-classroom/integrate-github-classroom-with-an-ide)"

content/education/manage-coursework-with-github-classroom/manage-classrooms.md

@@ -116,6 +116,6 @@ You can archive a classroom that you no longer use on {% data variables.product.
   !["Delete repository" button](/assets/images/help/classroom/click-delete-classroom-button.png)
 1. **Read the warnings**.
 1. To verify that you're deleting the correct classroom, type the name of the classroom you want to delete.
-  ![Modal for deleting a classrom with warnings and text field for classroom name](/assets/images/help/classroom/delete-classroom-modal-with-warning.png)
+  ![Modal for deleting a classroom with warnings and text field for classroom name](/assets/images/help/classroom/delete-classroom-modal-with-warning.png)
 1. Click **Delete classroom**.
   !["Delete classroom" button](/assets/images/help/classroom/delete-classroom-click-delete-classroom-button.png)

content/education/teach-and-learn-with-github-education/apply-for-a-student-developer-pack.md

@@ -18,7 +18,7 @@ To be eligible for the {% data variables.product.prodname_student_pack %}, you m
 - Have a [{% data variables.product.prodname_dotcom %} user account](/articles/signing-up-for-a-new-github-account)
 - Be at least 13 years old
 
-Documents that prove your current student status include a picture of your school ID, class schedule, transcript, and affiliation or enrollment verification letter.
+Documents that prove your current student status include a picture of your school ID with current enrollment date, class schedule, transcript, and affiliation or enrollment verification letter.
 
 During your tenure as a student, you may be prompted to periodically re-verify your current academic status.