Merge branch 'main' into patch-1

.devcontainer.json

@@ -2,13 +2,12 @@
 // For format details, see https://aka.ms/vscode-remote/devcontainer.json 
 {
     "name": "docs.github.com",
-    "service": "container-doc",
     "settings": {
         "terminal.integrated.shell.linux": "/bin/bash",
         "cSpell.language": ",en"
     },
-    // Install pre-requisites, and start to serve docs.github.com locally
-    "postCreateCommand": "npm install && npm start",
+    // Install pre-requisites and run a build to ensure we are ready to start serving docs.github.com locally (via `npm start`)
+    "postCreateCommand": "npm ci && npm run build",
     "forwardPorts": [4000],
     // Visual Studio Code extensions which help authoring for docs.github.com.
     "extensions": [

.github/CODEOWNERS

@@ -1,6 +1,6 @@
 # Order is important. The LAST matching pattern has the MOST precedence.
 # gitignore style patterns are used, not globs.
-# https://help.github.com/articles/about-codeowners
+# https://docs.github.com/articles/about-codeowners
 # https://git-scm.com/docs/gitignore
 
 # Engineering

.github/ISSUE_COMMENT_TEMPLATE/target-date.yml

@@ -0,0 +1,14 @@
+---
+name: Target Date Update
+about: Target date update
+body:
+  - type: input
+    attributes:
+      name: Target completion date
+      placeholder: With context if the target completion date has changed
+      inputType: text
+  - type: input
+    attributes:
+      name: 'Attribution'
+      value: '_created with :heart: by typing_ `/status`'
+      inputType: text

.github/ISSUE_TEMPLATE/partner-contributed-documentation.md

@@ -0,0 +1,48 @@
+---
+name: Partner-owned product documentation
+about: Initiate a set of tasks to be completed by a GitHub partner wishing to document how their product works with GitHub
+title: ''
+labels:
+- partner
+assignees: ''
+---
+
+<!--
+Thank you for your interest in contributing to the GitHub documentation.
+
+This issue template is only for use by GitHub's Technology Partners who wish to contribute documentation explaining how the partner's product works with GitHub, making it straightforward for our shared customers to adopt the product into their workflow.
+
+As a general guide, we estimate we have bandwidth for prioritizing and reviewing up to 3 partner contributions per quarter.
+
+Please be sure to complete all items in the checklists that follow, and feel free to comment with any questions. A member of the team will be glad to support you.
+-->
+
+## Pre-requisites
+
+- [ ] Prior to submitting documentation, please apply to join the GitHub Technology Partner Program: [partner.github.com/apply](https://partner.github.com/apply?partnershipType=Technology+Partner). Please feel free to proceed once your application is approved.
+
+## What information would you like to add to docs.github.com?
+<!-- Please explain what your proposed article is about, what customers it benefits, and any other information that would help us to prioritize this request -->
+
+## Tasks
+
+Please be sure to complete each of the following:
+
+**Third-party product documentation:**
+
+- [ ] MUST follow our [general contributing guidelines](CONTRIBUTING.md) for voice and markup format.
+- [ ] MUST emphasize how the third-party product works with GitHub.
+- [ ] MUST be written in Markdown format, using [one of the templates provided](contributing/github-partners/README.md#templates)
+- [ ] MUST include the name and URL of the GitHub technology partner responsible for maintenance of the documentation being contributed. This should be added via the `contributor.name` and `contributor.URL` properties in the template's YAML frontmatter.
+- [ ] MUST be proposed via a pull request to this repo following [the GitHub Flow](https://guides.github.com/introduction/flow/).
+- [ ] MUST be located in the root of [the `content` folder](content). Your filename MUST match the GitHub technology partner name, and use the `.md` file extension.
+
+**The `Pull Request`:**
+
+- [ ] MUST reference this issue, e.g. via `closes #<this issue number>`
+- [ ] MUST pass the automated CI checks
+- [ ] MUST include links to supporting material demonstrating the functionality being documented (this can be a link to a public GitHub repo, _or_ a video / screencast walkthrough)
+
+Once all tasks are completed, please mention `@github/docs-content` for next steps.
+
+/cc @github/partner-engineering for :eyes:

.github/ISSUE_TEMPLATE/production-config-change.md

@@ -0,0 +1,24 @@
+---
+name: Change production configuration
+about: Track changes to the production docs.github.com site
+title: ''
+labels: engineering
+assignees: ''
+---
+
+A configuration change would be something outside of our code that we change with our production environment, such as environment variables, virtual machine tier or quantity, or service providers.
+
+- _Primary person_:
+- _Second person_:
+- _When_:
+- _Zoom URL_:
+
+### What is the configuration change?
+
+### Why are we updating this configuration?
+
+### What risks are there with this configuration change?
+
+### If an issue happens, how do we roll back?
+
+Once the change is verified good, please close this issue.

.github/allowed-actions.js

@@ -11,6 +11,8 @@ module.exports = [
   "actions/setup-node@c46424eee26de4078d34105d3de3cc4992202b1e", //actions/setup-node@v2.1.4
   "ruby/setup-ruby@fdcfbcf14ec9672f6f615cb9589a1bc5dd69d262", //ruby/setup-ruby@vv1.64.1
   "actions/stale@9d6f46564a515a9ea11e7762ab3957ee58ca50da", //actions/stale@v3.0.16
+  "alex-page/github-project-automation-plus@fdb7991b72040d611e1123d2b75ff10eda9372c9",
+  "andymckay/labeler@22d5392de2b725cea4b284df5824125054049d84",
   "archive/github-actions-slack@d368c5a4ad757515a9344918f84c490b05777d94",
   "ashley-taylor/regex-property-action@93a24f845cd20790924208225cc72da8b4c6d46d",
   "crowdin/github-action@fd9429dd63d6c0f8a8cb4b93ad8076990bd6e688",
@@ -37,6 +39,6 @@ module.exports = [
   "repo-sync/pull-request@33777245b1aace1a58c87a29c90321aa7a74bd7d",
   "someimportantcompany/github-actions-slack-message@0b470c14b39da4260ed9e3f9a4f1298a74ccdefd",
   "tjenkinson/gh-action-auto-merge-dependency-updates@4d7756c04d9d999c5968697a621b81c47f533d61",
-  "EndBug/add-and-commit@9358097a71ad9fb9e2f9624c6098c89193d83575",
+  "EndBug/add-and-commit@b3c7c1e078a023d75fb0bd326e02962575ce0519",
   "dorny/paths-filter@eb75a1edc117d3756a18ef89958ee59f9500ba58",
 ];

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

@@ -1,4 +1,9 @@
 name: 60 Days Stale Check
+
+# **What it does**: Pull requests older than 60 days will be flagged as stale.
+# **Why we have it**: We want to manage our queue of issues and pull requests.
+# **Who does it impact**: Everyone that works on docs or docs-internal.
+
 on:
   schedule:
     - cron: '40 16 * * *' # Run each day at 16:40 UTC / 8:40 PST

.github/workflows/auto-label-prs.yml

@@ -1,5 +1,9 @@
 name: Auto label Pull Requests
 
+# **What it does**: Automatically adds the engineering label when specific files change.
+# **Why we have it**: Other automation applies specifically to engineering label issues and pull requests.
+# **Who does it impact**: Automation that relies on the engineering label.
+
 on:
   pull_request:
 

.github/workflows/automerge-dependencies.yml

@@ -1,5 +1,9 @@
 name: Auto Merge Dependency Updates
 
+# **What it does**: Automatically merge pull requests from dependabot.
+# **Why we have it**: To keep our dependencies up-to-date, to avoid security issues.
+# **Who does it impact**: It helps docs engineering focus on higher value work.
+
 on:
   pull_request:
     paths:

.github/workflows/automerge.yml

@@ -1,4 +1,9 @@
 name: automerge
+
+# **What it does**: Pull requests with label "automerge" or "autosquash" will automatically merge.
+# **Why we have it**: While now this is a feature built into GitHub, we still use it as part of other automation.
+# **Who does it impact**: Any workflows that depend on automerge or autosquash labels.
+
 on:
   pull_request:
     types:

.github/workflows/autoupdate-branch.yml

@@ -1,5 +1,9 @@
 name: autoupdate branch
 
+# **What it does**: Any pull requests with "autoupdate" label will get main branch updates.
+# **Why we have it**: Our repo-sync automation relies on it.
+# **Who does it impact**: Our ability to support the open-source repository.
+
 #
 # This workflow checks all open PRs targeting `main` as their base branch and
 # will attempt to update them if they have the `autoupdate` label applied.
@@ -17,8 +21,6 @@ on:
   push:
     branches:
       - main
-  schedule:
-    - cron: '*/30 * * * *' # every 30 minutes
 
 jobs:
   autoupdate:

.github/workflows/browser-test.yml

@@ -1,5 +1,9 @@
 name: Browser Tests
 
+# **What it does**: This runs our browser tests on pull requests.
+# **Why we have it**: This is the only way we currently test our browser JavaScript.
+# **Who does it impact**: Docs engineering, open-source engineering contributors.
+
 on:
   workflow_dispatch:
   push:

.github/workflows/build-docker-image.yml

@@ -1,7 +1,9 @@
-# Make sure the Docker container still builds
-
 name: Build Docker image
 
+# **What it does**: This builds our Docker container.
+# **Why we have it**: We don't use the Docker container internally, but other teams depend on our Docker container.
+# **Who does it impact**: Enterprise customers.
+
 on:
   push:
     branches:
@@ -14,7 +16,7 @@ env:
 jobs:
   build:
     # Do not run this job for translations PRs
-    if: ${{ github.ref != 'refs/heads/translations' }}
+    if: ${{ github.head_ref != 'translations' && github.ref != 'refs/heads/translations' }}
 
     runs-on: ubuntu-latest
     steps:

.github/workflows/check-all-english-links.yml

@@ -1,5 +1,9 @@
 name: Check all English links
 
+# **What it does**: This script once a day checks all English links and reports in issues.
+# **Why we have it**: We want to know if any links break.
+# **Who does it impact**: Docs content.
+
 on:
   workflow_dispatch:
   schedule:

.github/workflows/check-for-spammy-issues.yml

@@ -1,4 +1,9 @@
 name: Check for Spammy Issues
+
+# **What it does**: This action closes low value pull requests in the open-source repository.
+# **Why we have it**: We get lots of spam in the open-source repository.
+# **Who does it impact**: Open-source contributors.
+
 on:
   issues:
     types: [opened]
@@ -32,7 +37,7 @@ jobs:
               return
             } catch(err) {
               // An error will be thrown if the user is not a GitHub employee
-              // If a user is not a GitHub employee, we should check to see if title has at least the minimum required number of words in it and if it does, we can exit the workflow 
+              // If a user is not a GitHub employee, we should check to see if title has at least the minimum required number of words in it and if it does, we can exit the workflow
 
               if(titleWordCount > titleWordCountMin) {
                 return
@@ -42,7 +47,7 @@ jobs:
             //
             // Assuming the user is not a GitHub employee and the issue title
             // has the minimum number of words required, proceed.
-            // 
+            //
 
             // Close the issue and add the invalid label
             await github.issues.update({

.github/workflows/close-external-repo-sync-prs.yml

@@ -1,5 +1,9 @@
 name: Check for External Repo Sync PR
 
+# **What it does**: If someone made a repo sync pull request other than Octomerger, close it.
+# **Why we have it**: Another form of spam in the open-source repository.
+# **Who does it impact**: Open-source contributors.
+
 on:
   pull_request:
     types:
@@ -11,7 +15,7 @@ on:
 jobs:
   invalid-repo-sync-check:
     name: Close external Repo Sync PRs
-    if: ${{ github.repository == 'github/docs' && github.ref == 'refs/heads/repo-sync' }}
+    if: ${{ github.repository == 'github/docs' && github.head_ref == 'repo-sync' }}
     runs-on: ubuntu-latest
     steps:
       - uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9

.github/workflows/codeql.yml

@@ -1,5 +1,9 @@
 name: CodeQL analysis
 
+# **What it does**: This runs CodeQL on our repository.
+# **Why we have it**: Security scanning.
+# **Who does it impact**: Docs engineering.
+
 on:
   push:
     branches:

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

@@ -1,5 +1,9 @@
 name: Confirm internal staff meant to post in public
 
+# **What it does**: If a GitHub staff makes an issue/pull request in the open-source repo, creates an issue in the internal one to verify intent.
+# **Why we have it**: We don't want GitHub staff accidentally making issues/pull requests in the wrong repository.
+# **Who does it impact**: GitHub staff.
+
 on:
   issues:
     types:

.github/workflows/crowdin.yml

@@ -1,5 +1,9 @@
 name: Crowdin Sync
 
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**: Docs localization.
+
 on:
   workflow_dispatch:
   schedule:

.github/workflows/dry-run-sync-algolia-search-indices.yml

@@ -1,5 +1,9 @@
 name: (Dry run) Algolia
 
+# **What it does**: On request, dry run Algolia to check for issues with search indexing.
+# **Why we have it**: It helps us debug issues with search indexing.
+# **Who does it impact**: Docs engineering.
+
 on:
   workflow_dispatch:
 

.github/workflows/first-responder-docs-content.yml

@@ -1,4 +1,9 @@
 name: First responder docs-content
+
+# **What it does**: New pull requests automatically add to the content first responder board.
+# **Why we have it**: So we don't lose track of new pull reuqests for docs-content to review.
+# **Who does it impact**: Docs content.
+
 on:
   pull_request:
     types:

.github/workflows/js-lint.yml

@@ -1,5 +1,9 @@
 name: Lint JS
 
+# **What it does**: Lints our JavaScript to ensure the code matches the specified code style.
+# **Why we have it**: We want some level of consistency to our JavaScript.
+# **Who does it impact**: Docs engineering, open-source engineering contributors.
+
 on:
   workflow_dispatch:
   push:

.github/workflows/link-check-dotcom.yml

@@ -1,5 +1,9 @@
 name: 'Link Checker: Dotcom'
 
+# **What it does**: This checks links for dotcom version of docs.
+# **Why we have it**: We want to know if links break.
+# **Who does it impact**: Docs content.
+
 on:
   workflow_dispatch:
   push:
@@ -47,7 +51,7 @@ jobs:
       #   run: npm run heroku-postbuild
       #   env:
       #     DOCUBOT_REPO_PAT: ${{ secrets.DOCUBOT_REPO_PAT }}
-      #     GIT_BRANCH: ${{ github.ref }}
+      #     GIT_BRANCH: ${{ github.head_ref || github.ref }}
 
       - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
         name: Build

.github/workflows/link-check-ghae.yml

@@ -1,5 +1,9 @@
 name: 'Link Checker: GitHub AE'
 
+# **What it does**: This checks links for GHAE version of docs.
+# **Why we have it**: We want to know if links break.
+# **Who does it impact**: Docs content.
+
 on:
   workflow_dispatch:
   push:
@@ -47,7 +51,7 @@ jobs:
       #   run: npm run heroku-postbuild
       #   env:
       #     DOCUBOT_REPO_PAT: ${{ secrets.DOCUBOT_REPO_PAT }}
-      #     GIT_BRANCH: ${{ github.ref }}
+      #     GIT_BRANCH: ${{ github.head_ref || github.ref }}
 
       - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
         name: Build

.github/workflows/link-check-ghes.yml

@@ -1,5 +1,9 @@
 name: 'Link Checker: Enterprise Server'
 
+# **What it does**: This checks links for GHES version of docs.
+# **Why we have it**: We want to know if links break.
+# **Who does it impact**: Docs content.
+
 on:
   workflow_dispatch:
   push:
@@ -47,7 +51,7 @@ jobs:
       #   run: npm run heroku-postbuild
       #   env:
       #     DOCUBOT_REPO_PAT: ${{ secrets.DOCUBOT_REPO_PAT }}
-      #     GIT_BRANCH: ${{ github.ref }}
+      #     GIT_BRANCH: ${{ github.head_ref || github.ref }}
 
       - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' }}
         name: Build

.github/workflows/merged-notification.yml

@@ -1,4 +1,9 @@
 name: Merged notification
+
+# **What it does**: When we merge an open-source pull request, we want to set expectations that deployment may take awhile.
+# **Why we have it**: We deploy to production from docs-internal, not docs.
+# **Who does it impact**: Open-source contributors.
+
 on:
   pull_request_target:
     types:

.github/workflows/move-help-wanted-issues.yml

@@ -0,0 +1,22 @@
+name: Move help wanted issues
+
+# **What it does**: In the open source repo, when the "help wanted" or "good first issue" labels are added to an issue, the issue is added to the "Help wanted" column on the project board.
+# **Why we have it**: To keep track of help wanted issues.
+# **Who does it impact**: Open-source contributors.
+
+on:
+  issues:
+    types:
+      - labeled
+
+jobs:
+  move_issues:
+    if: github.repository == 'github/docs' && (github.event.label.name == 'help wanted' || github.event.label.name == 'good first issue')
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: alex-page/github-project-automation-plus@fdb7991b72040d611e1123d2b75ff10eda9372c9
+        with:
+          project: Docs team reviews
+          column: Help wanted
+          repo-token: ${{ secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES }}

.github/workflows/move-ready-to-merge-issues.yaml

@@ -0,0 +1,27 @@
+name: Move and unlabel ready to merge issues
+
+# **What it does**: This moves ready to merge issues on the project board for the open source repo. When an issue in the open source repo is labeled "ready to merge," the "waiting for review" label is removed and the issue is moved to the "Triage" column.
+# **Why we have it**:  To help with managing our project boards.
+# **Who does it impact**: Open source contributors, open-source maintainers.
+
+on:
+  pull_request:
+    types:
+      - labeled
+
+jobs:
+  unmark_for_review:
+    if: github.repository == 'github/docs' && github.event.label.name == 'ready to merge'
+    runs-on: ubuntu-latest
+    steps:
+      - name: move issue
+        uses: alex-page/github-project-automation-plus@fdb7991b72040d611e1123d2b75ff10eda9372c9
+        with:
+          project: Docs team reviews
+          column: Triage
+          repo-token: ${{ secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES }}
+      - name: remove label
+        uses: andymckay/labeler@22d5392de2b725cea4b284df5824125054049d84
+        with:
+          remove-labels: 'waiting for review'
+          repo-token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/openapi-decorate.yml

@@ -1,5 +1,9 @@
 name: OpenAPI generate decorated schema files
 
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
 on:
   workflow_dispatch:
   pull_request:
@@ -25,13 +29,10 @@ jobs:
         run: script/rest/update-files.js --decorate-only
 
       - name: Check in the decorated files
-        uses: EndBug/add-and-commit@9358097a71ad9fb9e2f9624c6098c89193d83575
+        uses: EndBug/add-and-commit@b3c7c1e078a023d75fb0bd326e02962575ce0519
         with:
           # The arguments for the `git add` command
           add: 'lib/rest/static/decorated'
 
           # The message for the commit
           message: 'Add decorated OpenAPI schema files'
-
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Leave this line unchanged

.github/workflows/openapi-schema-check.yml

@@ -1,5 +1,9 @@
 name: OpenAPI dev mode check
 
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
 on:
   workflow_dispatch:
   push:

.github/workflows/pa11y.yml

@@ -1,4 +1,9 @@
 name: Pa11y
+
+# **What it does**: Runs a static accessibility check on high traffic docs pages.
+# **Why we have it**: We want accessibility support for the docs.
+# **Who does it impact**: Docs engineering, users who need accessibility features.
+
 on:
   workflow_dispatch:
   schedule:

.github/workflows/ping-staging-apps.yml

@@ -1,5 +1,9 @@
 name: Ping staging apps
 
+# **What it does**: This keeps our staging applications from automatically spinning down.
+# **Why we have it**: Staging applications can hiberate without use.
+# **Who does it impact**: Anyone with a pull request in docs-internal.
+
 on:
   schedule:
     - cron: '*/20 * * * *' # every twenty minutes

.github/workflows/post-status-updates-to-slack.yml

@@ -1,4 +1,9 @@
 name: Epic Status Update
+
+# **What it does**: For our epic issue status comments, also ping us in Slack.
+# **Why we have it**: So that we can write one status update and have it show up in two places.
+# **Who does it impact**: GitHub docs staff.
+
 on:
   issue_comment:
     types: [created]

.github/workflows/ready-for-doc-review.yml

@@ -0,0 +1,22 @@
+name: Ready for docs-content review
+
+# **What it does**: Adds pull requests in the docs-internal repository to the docs-content first responder project board
+# **Why we have it**: So that other GitHub teams can easily request reviews from the docs-content team, and so that writers can see when a PR is ready for review
+# **Who does it impact**: Writers working in the docs-internal repository
+
+on:
+  pull_request:
+    types: [labeled]
+
+jobs:
+  request_doc_review:
+    name: Request a review from the docs-content team
+    if: github.event.label.name == 'ready-for-doc-review' && github.repository == 'github/docs-internal'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Add pull request to FR project board
+        uses: rachmari/actions-add-new-issue-to-column@1a459ef92308ba7c9c9dc2fcdd72f232495574a9
+        with:
+          action-token: ${{ secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES }}
+          project-url: 'https://github.com/orgs/github/projects/1367'
+          column-name: 'Docs-internal external contributor PRs'

.github/workflows/remove-from-fr-board.yaml

@@ -1,8 +1,12 @@
 name: Remove card from FR board
 
+# **What it does**: Removes the triggering issue or PR from the docs-content first responder board. This workflow is expected to trigger from a slash command.
+# **Why we have it**: To help with first responder duties
+# **Who does it impact**: Docs-content team first responders
+
 on:
   repository_dispatch:
-    types: remove_from_FR_board
+    types: remove_from_docs_FR_board
 
 jobs:
   remove_from_FR_board:

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

@@ -1,5 +1,9 @@
 name: Remove unused assets
 
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
 on:
   schedule:
     - cron: '20 15 * * 0' # run every Sunday at 20:15 UTC / 12:15 PST

.github/workflows/repo-freeze-check.yml

@@ -1,5 +1,9 @@
 name: Repo Freeze Check
 
+# **What it does**: Prevent pull requests from merging during freezes.
+# **Why we have it**: Sometimes we need to freeze deployments for various reasons.
+# **Who does it impact**: Anyone working on docs.
+
 on:
   workflow_dispatch:
   pull_request_target:

.github/workflows/repo-freeze-reminders.yml

@@ -1,5 +1,9 @@
 name: Repo Freeze Reminders
 
+# **What it does**: This reminds us that the repository is frozen for deploys.
+# **Why we have it**: To remind us to turn off the freeze after the freeze period is over.
+# **Who does it impact**: Docs engineering.
+
 on:
   schedule:
     - cron: '00 11 * * *' # once per day around 11:00am UTC

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

@@ -1,5 +1,9 @@
 name: Repo Sync Stalls
 
+# **What it does**: This lets us know in Slack if repo-sync doesn't happen in a timely manner.
+# **Why we have it**: We want repo-sync to keep the two repositories in sync with each other.
+# **Who does it impact**: Open-source contributors, docs engineering.
+
 on:
   workflow_dispatch:
   schedule:
@@ -30,7 +34,7 @@ jobs:
               return
             }
 
-            // Remove all pull requests that don't have the 
+            // 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')
@@ -42,7 +46,7 @@ jobs:
               const minutesOpen = timeDelta / 1000 / 60;
 
               if (minutesOpen > 180) {
-                core.setFailed('Repo sync appears to be stalled') 
+                core.setFailed('Repo sync appears to be stalled')
               }
             })
       - name: Send Slack notification if workflow fails

.github/workflows/repo-sync.yml

@@ -6,6 +6,10 @@
 
 name: Repo Sync
 
+# **What it does**: Syncs docs and docs-internal.
+# **Why we have it**: To keep the open-source repository up-to-date, while still having an internal repository for sensitive work.
+# **Who does it impact**: Open-source.
+
 on:
   workflow_dispatch:
   schedule:
@@ -40,7 +44,7 @@ jobs:
           destination_branch: main
           pr_title: 'repo sync'
           pr_body: "This is an automated pull request to sync changes between the public and private repos.\n\n:robot: This pull request should be merged (not squashed) to preserve continuity across repos, so please let a bot do the merging!"
-          pr_label: autoupdate,automated-reposync-pr
+          pr_label: automerge,autoupdate,automated-reposync-pr
           github_token: ${{ secrets.OCTOMERGER_PAT_WITH_REPO_AND_WORKFLOW_SCOPE }}
 
       - name: Find pull request
@@ -88,32 +92,6 @@ jobs:
               console.log(`Branch is already up-to-date`)
             }
 
-      - name: Enable GitHub auto-merge
-        if: ${{ steps.find-pull-request.outputs.number }}
-        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
-        with:
-          github-token: ${{ secrets.GITHUB_TOKEN }}
-          script: |
-            const pull = await github.pulls.get({
-              ...context.repo,
-              pull_number: parseInt(${{ steps.find-pull-request.outputs.number }})
-            })
-
-            const pullNodeId = pull.data.node_id
-            console.log(`Pull request GraphQL Node ID: ${pullNodeId}`)
-
-            const mutation = `mutation ($id: ID!) {
-              enablePullRequestAutoMerge(input: {
-                pullRequestId: $id,
-                mergeMethod: MERGE
-              })
-            }`
-            const variables = {
-              id: pullNodeId
-            }
-            await github.graphql(mutation, variables)
-            console.log('Auto-merge enabled!')
-
       - name: Send Slack notification if workflow fails
         uses: someimportantcompany/github-actions-slack-message@0b470c14b39da4260ed9e3f9a4f1298a74ccdefd
         if: failure()

.github/workflows/send-crowdin-prs-to-boards.yml

@@ -0,0 +1,38 @@
+name: Send Crowdin PRs to boards
+
+on:
+  pull_request:
+    types:
+      - opened
+
+jobs:
+  triage:
+    if: github.repository == 'github/docs-internal' && github.event.pull_request.head.ref == 'translations'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+        with:
+          github-token: ${{ secrets.DOCUBOT_READORG_REPO_WORKFLOW_SCOPES }}
+          script: |
+            var squadBoardColumnId = 13447153; // Add to the team backlog/squad board
+
+            try {
+              await github.projects.createCard({
+                column_id: squadBoardColumnId,
+                content_id: context.payload.issue.id,
+                content_type: "Issue"
+              });
+            } catch (error) {
+              console.log(error);
+            }
+
+            var prBoardColumnId = 10095775; // Add to the pull requests board
+            try {
+              await github.projects.createCard({
+                column_id: prBoardColumnId,
+                content_id: context.payload.issue.id,
+                content_type: "Issue"
+              });
+            } catch (error) {
+              console.log(error);
+            }

.github/workflows/send-eng-issues-to-backlog.yml

@@ -1,30 +0,0 @@
-name: Send Issue to EPD backlog
-
-on:
-  issues:
-    types:
-      - labeled
-      - reopened
-
-jobs:
-  triage:
-    if: github.repository == 'github/docs-internal'
-    runs-on: ubuntu-latest
-    continue-on-error: true
-    steps:
-      - name: Add issues with engineering label to project board
-        if: contains(github.event.issue.labels.*.name, 'engineering') || contains(github.event.issue.labels.*.name, 'design') || contains(github.event.issue.labels.*.name, 'Design')
-        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
-        with:
-          github-token: ${{ secrets.DOCUBOT_FR_PROJECT_BOARD_WORKFLOWS_REPO_ORG_READ_SCOPES }}
-          script: |
-            var column_id = 9659080;
-            try {
-              github.projects.createCard({
-                column_id: column_id,
-                content_id: context.payload.issue.id,
-                content_type: "Issue"
-              });
-            } catch (error) {
-              console.log(error);
-            }

.github/workflows/send-issues-to-how-how-we-work-boards.yml

@@ -0,0 +1,63 @@
+name: Send Issue to How We Work Boards
+
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
+on:
+  issues:
+    types:
+      - labeled
+      - opened
+      - reopened
+
+jobs:
+  triage:
+    runs-on: ubuntu-latest
+    continue-on-error: true
+    steps:
+      - if: contains(github.event.issue.labels.*.name, 'engineering') && !contains(github.event.issue.labels.*.name, 'feature') && !contains(github.event.issue.labels.*.name, 'epic')
+        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+        with:
+          github-token: ${{ secrets.DOCUBOT_READORG_REPO_WORKFLOW_SCOPES }}
+          script: |
+            var column_id = 9659080;
+            try {
+              github.projects.createCard({
+                column_id: column_id,
+                content_id: context.payload.issue.id,
+                content_type: "Issue"
+              });
+            } catch (error) {
+              console.log(error);
+            }
+      - if: contains(github.event.issue.labels.*.name, 'engineering') && contains(github.event.issue.labels.*.name, 'feature')
+        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+        with:
+          github-token: ${{ secrets.DOCUBOT_READORG_REPO_WORKFLOW_SCOPES }}
+          script: |
+            var column_id = 13445681;
+            try {
+              github.projects.createCard({
+                column_id: column_id,
+                content_id: context.payload.issue.id,
+                content_type: "Issue"
+              });
+            } catch (error) {
+              console.log(error);
+            }
+      - if: contains(github.event.issue.labels.*.name, 'engineering') && contains(github.event.issue.labels.*.name, 'epic')
+        uses: actions/github-script@626af12fe9a53dc2972b48385e7fe7dec79145c9
+        with:
+          github-token: ${{ secrets.DOCUBOT_READORG_REPO_WORKFLOW_SCOPES }}
+          script: |
+            var column_id = 13445932;
+            try {
+              github.projects.createCard({
+                column_id: column_id,
+                content_id: context.payload.issue.id,
+                content_type: "Issue"
+              });
+            } catch (error) {
+              console.log(error);
+            }

.github/workflows/site-policy-sync.yml

@@ -1,5 +1,9 @@
 name: site-policy-sync
 
+# **What it does**: Updates our site policy docs when changes happen to site policy.
+# **Why we have it**: We want up to date site policy docs.
+# **Who does it impact**: Site policy team.
+
 # Controls when the action will run.
 on:
   # Triggers the workflow pull requests merged to the main branch

.github/workflows/start-new-engineering-pr-workflow.yml

@@ -1,5 +1,9 @@
 name: Start new engineering PR workflow
 
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
 on:
   pull_request_target:
     types:

.github/workflows/sync-algolia-search-indices.yml

@@ -1,5 +1,9 @@
 name: Algolia
 
+# **What it does**: This updates our search indexes after each deployment.
+# **Why we have it**: We want our search indexes kept up to date.
+# **Who does it impact**: Anyone using search on docs.
+
 on:
   workflow_dispatch:
   push:

.github/workflows/sync-single-english-algolia-index.yml

@@ -1,5 +1,9 @@
 name: Algolia Sync Single English Index
 
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
 on:
   pull_request:
     types:

.github/workflows/test-windows.yml

@@ -1,17 +1,25 @@
-# NOTE: Changes to this file should also be applied to './test.yml' and './test-translations.yml'
+# NOTE: Changes to this file should also be applied to './test.yml'
 
 name: Node.js Tests - Windows
 
+# **What it does**: This runs our tests on Windows.
+# **Why we have it**: We want to support Windows contributors to docs.
+# **Who does it impact**: Anyone working on docs on a Windows device.
+
 on:
   workflow_dispatch:
   pull_request:
   schedule:
     - cron: '50 19 * * *' # once a day at 19:50 UTC / 11:50 PST
 
+env:
+  CI: true
+
 jobs:
   test:
     runs-on: windows-latest
     if: (github.event_name != 'pull_request') || (github.event_name == 'pull_request' && (contains(github.event.pull_request.labels.*.name, 'Windows') || contains(github.event.pull_request.labels.*.name, 'windows')))
+    timeout-minutes: 60
     strategy:
       fail-fast: false
       matrix:
@@ -19,6 +27,9 @@ jobs:
     steps:
       - name: Check out repo
         uses: actions/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f
+        with:
+          # Enables cloning the Early Access repo later with the relevant PAT
+          persist-credentials: 'false'
 
       - name: Setup node
         uses: actions/setup-node@c46424eee26de4078d34105d3de3cc4992202b1e
@@ -41,7 +52,15 @@ jobs:
       - name: Install dependencies
         run: npm ci
 
-      - name: Run build script
+      - if: ${{ github.repository == 'github/docs-internal' }}
+        name: Clone early access
+        run: npm run heroku-postbuild
+        env:
+          DOCUBOT_REPO_PAT: ${{ secrets.DOCUBOT_REPO_PAT }}
+          GIT_BRANCH: ${{ github.head_ref || github.ref }}
+
+      - if: ${{ github.repository != 'github/docs-internal' }}
+        name: Run build script
         run: npm run build
 
       - name: Run tests

.github/workflows/test.yml

@@ -2,6 +2,10 @@
 
 name: Node.js Tests
 
+# **What it does**: Runs our tests.
+# **Why we have it**: We want our tests to pass before merging code.
+# **Who does it impact**: Docs engineering, open-source engineering contributors.
+
 on:
   workflow_dispatch:
   push:
@@ -77,7 +81,7 @@ jobs:
         run: npm run heroku-postbuild
         env:
           DOCUBOT_REPO_PAT: ${{ secrets.DOCUBOT_REPO_PAT }}
-          GIT_BRANCH: ${{ github.ref }}
+          GIT_BRANCH: ${{ github.head_ref || github.ref }}
 
       - if: ${{ needs.see_if_should_skip.outputs.should_skip != 'true' && github.repository != 'github/docs-internal' }}
         name: Run build script

.github/workflows/translations.yml

@@ -1,5 +1,9 @@
 name: Translations
 
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**: Docs localization
+
 on:
   schedule:
     - cron: '20 19 * * *' # once a day at 19:20 UTC / 11:20 PST

.github/workflows/triage-issue-comments.yml

@@ -1,4 +1,9 @@
 name: Triage new issue comments
+
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
 on:
   issue_comment:
     types:

.github/workflows/triage-issues.yml

@@ -1,4 +1,9 @@
 name: Triage new issues
+
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
 on:
   issues:
     types:

.github/workflows/triage-pull-requests.yml

@@ -1,4 +1,9 @@
 name: Triage new pull requests
+
+# **What it does**:
+# **Why we have it**:
+# **Who does it impact**:
+
 on:
   pull_request:
     types:

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

@@ -1,4 +1,9 @@
 name: Public Repo Stale Check
+
+# **What it does**: Provides more aggressive stale checks in the open repo.
+# **Why we have it**: In the open repo, we want more aggressive stale checking.
+# **Who does it impact**: Anyone working in the open repo.
+
 on:
   schedule:
     - cron: '45 16 * * *' # Run each day at 16:45 UTC / 8:45 PST

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

@@ -1,5 +1,9 @@
 name: Check unallowed file changes
 
+# **What it does**: If someone changes some files in the open repo, we prevent the pull request from merging.
+# **Why we have it**: Some files can only be changed in the internal repository for security and workflow reasons.
+# **Who does it impact**: Open source contributors.
+
 on:
   pull_request_target:
     paths:

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

@@ -1,5 +1,9 @@
 name: Update GraphQL files
 
+# **What it does**: This updates our GraphQL schemas.
+# **Why we have it**: We want our GraphQL docs up to date.
+# **Who does it impact**: Docs engineering, people reading GraphQL docs.
+
 on:
   workflow_dispatch:
   schedule:

.github/workflows/workflow-lint.yml

@@ -1,5 +1,9 @@
 name: Lint workflows
 
+# **What it does**: This lints our workflow files.
+# **Why we have it**: We want some level of consistency in our workflow files.
+# **Who does it impact**: Docs engineering.
+
 on:
   workflow_dispatch:
   push:

.github/workflows/yml-lint.yml

@@ -1,5 +1,9 @@
 name: Lint Yaml
 
+# **What it does**: This lints our yaml files in the docs repository.
+# **Why we have it**: We want some level of consistent formatting for YAML files.
+# **Who does it impact**: Docs engineering, docs content.
+
 on:
   workflow_dispatch:
   push:

app.json

@@ -3,7 +3,8 @@
   "env": {
     "NODE_ENV": "production",
     "NPM_CONFIG_PRODUCTION": "true",
-    "ENABLED_LANGUAGES": "en"
+    "ENABLED_LANGUAGES": "en",
+    "WEB_CONCURRENCY": "1"
   },
   "buildpacks": [
     { "url": "heroku/nodejs" }

content/README.md

@@ -25,6 +25,7 @@ See the [contributing docs](/CONTRIBUTING.md) for general information about work
   - [`includeGuides`](#includeGuides)
   - [`type`](#type)
   - [`topics`](#topics)
+  - [`contributor`](#contributor)
   - [Escaping single quotes](#escaping-single-quotes)
 - [Autogenerated mini TOCs](#autogenerated-mini-tocs)
 - [Versioning](#versioning)
@@ -227,10 +228,22 @@ includeGuides:
 - Optional.
 
 ### `topics`
-- Purpose: Indicate the topics covered by the article.
-- Type: `String`
+- Purpose: Indicate the topics covered by the article. The topics are used to filter guides on some landing pages. For example, the guides at the bottom of [this page](https://docs.github.com/en/actions/guides) can be filtered by topics and the topics are listed under the guide intro. Topics are also added to all search records that get created for each page. The search records contain a `topics` property that is used to filter search results by topics. For more information, see the [Search](/contributing/search.md) contributing guide. Refer to the content models for more details around adding topics. A full list of  existing topics is located in the [allowed topics file](/data/allowed-topics.js). If topics in article frontmatter and the allow-topics list become out of sync, the [topics CI test](/tests/unit/search/topics.js) will fail.
+- Type: Array of `String`s
+- Optional: Topics are preferred for each article, but, there may be cases where existing articles don't yet have topics or a adding a topic to a new article may not add value.
+
+### `contributor`
+- Purpose: Indicate an article is contributed and maintained by a third-party organization, typically a GitHub Technology Partner.
+- Type: `Object`. Properties are `name` and `URL`.
 - Optional.
 
+Example:
+
+```yml
+contributor:
+  name: ACME, inc.
+  URL: https://acme.example.com/
+```
 
 ### Escaping single quotes
 

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

@@ -53,6 +53,26 @@ For a definition of common terms, see "[Core concepts for {% data variables.prod
 
 Browse the complete list of CI workflow templates offered by {% data variables.product.product_name %} in the {% if currentVersion == "free-pro-team@latest" %}[actions/starter-workflows](https://github.com/actions/starter-workflows/tree/main/ci) repository{% else %} `actions/starter-workflows` repository on {% data variables.product.product_location %}{% endif %}.
 
+### Skipping workflow runs
+
+If you want to temporarily prevent a workflow from being triggered, you can add a skip instruction to the commit message. Workflows that would otherwise be triggered `on: push` or `on: pull_request`, won't be triggered if you add any any of the following strings to the commit message in a push, or the HEAD commit of a pull request:
+
+* `[skip ci]`
+* `[ci skip]`
+* `[no ci]`
+* `[skip actions]`
+* `[actions skip]`
+
+Alternatively, you can end the commit message with two empty lines followed by either `skip-checks: true` or `skip-checks:true`.
+
+You won't be able to merge the pull request if your repository is configured to require specific checks to pass first. To allow the pull request to be merged you can push a new commit to the pull request without the skip instruction in the commit message.
+
+{% note %}
+
+**Note:** Skip instructions only apply to the `push` and `pull_request` events. For example, adding `[skip ci]` to a commit message won't stop a workflow that's triggered `on: pull_request_target` from running.
+
+{% endnote %}
+
 ### Notifications for workflow runs
 
 {% data reusables.repositories.workflow-notifications %}

content/actions/guides/adding-labels-to-issues.md

@@ -0,0 +1,68 @@
+---
+title: Adding labels to issues
+intro: You can use {% data variables.product.prodname_actions %} to automatically label issues.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+  github-ae: '*'
+type: 'tutorial'
+topics:
+  - 'Workflows'
+  - 'Project management'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+{% data reusables.actions.ae-beta %}
+{% data reusables.actions.ae-self-hosted-runners-notice %}
+
+### Introduction
+
+This tutorial demonstrates how to use the [`andymckay/labeler` action](https://github.com/marketplace/actions/simple-issue-labeler) in a workflow to label newly opened or reopened issues. For example, you can add the `triage` label every time an issue is opened or reopened. Then, you can see all issues that need to be triaged by filtering for issues with the `triage` label.
+
+In the tutorial, you will first make a workflow file that uses the [`andymckay/labeler` action](https://github.com/marketplace/actions/simple-issue-labeler). Then, you will customize the workflow to suit your needs.
+
+### Creating the workflow
+
+1. {% data reusables.actions.choose-repo %}
+2. {% data reusables.actions.make-workflow-file %}
+3. Copy the following YAML contents into your workflow file.
+
+    {% raw %}
+    ```yaml{:copy}
+    name: Label issues
+    on:
+      issues:
+        types:
+          - reopened
+          - opened
+    jobs:
+      label_issues:
+        runs-on: ubuntu-latest
+        steps:
+          - name: Label issues
+            uses: andymckay/labeler@1.0.2
+            with:
+              add-labels: "triage"
+    ```
+    {% endraw %}
+4. Customize the parameters in your workflow file:
+   - Change the value for `add-labels` to the list of labels that you want to add to the issue. Separate multiple labels with commas. For example, `"help wanted, good first issue"`. For more information about labels, see "[Managing labels](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)."
+5. {% data reusables.actions.commit-workflow %}
+
+### Testing the workflow
+
+Every time an issue in your repository is opened or reopened, this workflow will add the labels that you specified to the issue.
+
+Test out your workflow by creating an issue in your repository.
+
+1. Create an issue in your repository. For more information, see "[Creating an issue](/github/managing-your-work-on-github/creating-an-issue)."
+2. To see the workflow run that was triggered by creating the issue, view the history of your workflow runs. For more information, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
+3. When the workflow completes, the issue that you created should have the specified labels added.
+
+### Next steps
+
+- To learn more about additional things you can do with the `andymckay/labeler` action, like removing labels or skipping this action if the issue is assigned or has a specific label, see the [`andymckay/labeler` action documentation](https://github.com/marketplace/actions/simple-issue-labeler).
+- To learn more about different events that can trigger your workflow, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows#issues)." The `andymckay/labeler` action only works on `issues`, `pull_request`, or `project_card` events.
+- [Search GitHub](https://github.com/search?q=%22uses:+andymckay/labeler%22&type=code) for examples of workflows using this action.

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

@@ -48,7 +48,7 @@ jobs:
 
     steps:
     - uses: actions/checkout@v2
-    - name: Setup .NET Core SDK ${{ matrix.dotnet }}
+    - name: Setup .NET Core SDK ${{ matrix.dotnet-version }}
       uses: actions/setup-dotnet@v1.7.2
       with:
         dotnet-version: ${{ matrix.dotnet-version }}

content/actions/guides/closing-inactive-issues.md

@@ -0,0 +1,77 @@
+---
+title: Closing inactive issues
+intro: You can use {% data variables.product.prodname_actions %} to comment on or close issues that have been inactive for a certain period of time.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+  github-ae: '*'
+type: 'tutorial'
+topics:
+  - 'Workflows'
+  - 'Project management'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+{% data reusables.actions.ae-beta %}
+{% data reusables.actions.ae-self-hosted-runners-notice %}
+
+### Introduction
+
+This tutorial demonstrates how to use the [`actions/stale` action](https://github.com/marketplace/actions/close-stale-issues) to comment on and close issues that have been inactive for a certain period of time. For example, you can comment if an issue has been inactive for 30 days to prompt participants to take action. Then, if no additional activity occurs after 14 days, you can close the issue.
+
+In the tutorial, you will first make a workflow file that uses the [`actions/stale` action](https://github.com/marketplace/actions/close-stale-issues). Then, you will customize the workflow to suit your needs.
+
+### Creating the workflow
+
+1. {% data reusables.actions.choose-repo %}
+2. {% data reusables.actions.make-workflow-file %}
+3. Copy the following YAML contents into your workflow file.
+
+    {% raw %}
+    ```yaml{:copy}
+    name: Close inactive issues
+    on:
+      schedule:
+        - cron: "30 1 * * *"
+
+    jobs:
+      close-issues:
+        runs-on: ubuntu-latest
+        steps:
+          - uses: actions/stale@v3
+            with:
+              days-before-issue-stale: 30
+              days-before-issue-close: 14
+              stale-issue-label: "stale"
+              stale-issue-message: "This issue is stale because it has been open for 30 days with no activity."
+              close-issue-message: "This issue was closed because it has been inactive for 14 days since being marked as stale."
+              days-before-pr-stale: -1
+              days-before-pr-close: -1
+              repo-token: ${{ secrets.GITHUB_TOKEN }}
+    ```
+    {% endraw %}
+4. Customize the parameters in your workflow file:
+   - Change the value for `on.schedule` to dictate when you want this workflow to run. In the example above, the workflow will run every day at 1:30 UTC. For more information about scheduled workflows, see "[Scheduled events](/actions/reference/events-that-trigger-workflows#scheduled-events)."
+   - Change the value for `days-before-issue-stale` to the number of days without activity before the `actions/stale` action labels an issue. If you never want this action to label issues, set this value to `-1`.
+   - Change the value for `days-before-issue-close` to the number of days without activity before the `actions/stale` action closes an issue. If you never want this action to close issues, set this value to `-1`.
+   - Change the value for `stale-issue-label` to the label that you want to apply to issues that have been inactive for the amount of time specified by `days-before-issue-stale`.
+   - Change the value for `stale-issue-message` to the comment that you want to add to issues that are labeled by the `actions/stale` action.
+   - Change the value for `close-issue-message` to the comment that you want to add to issues that are closed by the `actions/stale` action.
+5. {% data reusables.actions.commit-workflow %}
+
+### Expected results
+
+Based on the `schedule` parameter (for example, every day at 1:30 UTC), your workflow will find issues that have been inactive for the specified period of time and will add the specified comment and label. Additionally, your workflow will close any previously labeled issues if no additional activity has occurred for the specified period of time.
+
+{% data reusables.actions.schedule-delay %}
+
+You can view the history of your workflow runs to see this workflow run periodically. For more information, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
+
+This workflow will only label and/or close 30 issues at a time in order to avoid rate limit abuse. You can configure this with the `operations-per-run` setting. For more information, see the [`actions/stale` action documentation](https://github.com/marketplace/actions/close-stale-issues).
+
+### Next steps
+
+- To learn more about additional things you can do with the `actions/stale` action, like closing inactive pull requests, ignoring issues with certain labels or milestones, or only checking issues with certain labels, see the [`actions/stale` action documentation](https://github.com/marketplace/actions/close-stale-issues).
+- [Search GitHub](https://github.com/search?q=%22uses%3A+actions%2Fstale%22&type=code) for examples of workflows using this action.

content/actions/guides/commenting-on-an-issue-when-a-label-is-added.md

@@ -0,0 +1,70 @@
+---
+title: Commenting on an issue when a label is added
+intro: You can use {% data variables.product.prodname_actions %} to automatically comment on issues when a specific label is applied.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+  github-ae: '*'
+type: 'tutorial'
+topics:
+  - 'Workflows'
+  - 'Project management'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+{% data reusables.actions.ae-beta %}
+{% data reusables.actions.ae-self-hosted-runners-notice %}
+
+### Introduction
+
+This tutorial demonstrates how to use the [`peter-evans/create-or-update-comment` action](https://github.com/marketplace/actions/create-or-update-comment) to comment on an issue when a specific label is applied. For example, when the `help-wanted` label is added to an issue, you can add a comment to encourage contributors to work on the issue.
+
+In the tutorial, you will first make a workflow file that uses the [`peter-evans/create-or-update-comment` action](https://github.com/marketplace/actions/create-or-update-comment). Then, you will customize the workflow to suit your needs.
+
+### Creating the workflow
+
+1. {% data reusables.actions.choose-repo %}
+2. {% data reusables.actions.make-workflow-file %}
+3. Copy the following YAML contents into your workflow file.
+
+    {% raw %}
+    ```yaml{:copy}
+    name: Add comment
+    on:
+      issues:
+        types:
+          - labeled
+    jobs:
+      add-comment:
+        if: github.event.label.name == 'help-wanted'
+        runs-on: ubuntu-latest
+        steps:
+          - name: Add comment
+            uses: peter-evans/create-or-update-comment@v1
+            with:
+              issue-number: ${{ github.event.issue.number }}
+              body: |
+                This issue is available for anyone to work on. **Make sure to reference this issue in your pull request.** :sparkles: Thank you for your contribution! :sparkles:
+    ```
+    {% endraw %}
+4. Customize the parameters in your workflow file:
+   - Replace `help-wanted` in `if: github.event.label.name == 'help-wanted'` with the label that you want to act on. If you want to act on more than one label, separate the conditions with `||`. For example, `if: github.event.label.name == 'bug' || github.event.label.name == 'fix me'` will comment whenever the `bug` or `fix me` labels are added to an issue.
+   - Change the value for `body` to the comment that you want to add. GitHub flavored markdown is supported. For more information about markdown, see "[Basic writing and formatting syntax](/github/writing-on-github/basic-writing-and-formatting-syntax)."
+5. {% data reusables.actions.commit-workflow %}
+
+### Testing the workflow
+
+Every time an issue in your repository is labeled, this workflow will run. If the label that was added is one of the labels that you specified in your workflow file, the `peter-evans/create-or-update-comment` action will add the comment that you specified to the issue.
+
+Test your workflow by applying your specified label to an issue.
+
+1. Open an issue in your repository. For more information, see "[Creating an issue](/github/managing-your-work-on-github/creating-an-issue)."
+2. Label the issue with the specified label in your workflow file. For more information, see "[Managing labels](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)."
+3. To see the workflow run triggered by labeling the issue, view the history of your workflow runs. For more information, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
+4. When the workflow completes, the issue that you labeled should have a comment added.
+
+### Next steps
+
+- To learn more about additional things you can do with the `peter-evans/create-or-update-comment` action, like adding reactions, visit the [`peter-evans/create-or-update-comment` action documentation](https://github.com/marketplace/actions/create-or-update-comment).

content/actions/guides/index.md

@@ -62,6 +62,13 @@ includeGuides:
   - /actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions
   - /actions/learn-github-actions/migrating-from-jenkins-to-github-actions
   - /actions/learn-github-actions/migrating-from-travis-ci-to-github-actions
+  - /actions/guides/using-github-actions-for-project-management
+  - /actions/guides/closing-inactive-issues
+  - /actions/guides/scheduling-issue-creation
+  - /actions/guides/adding-labels-to-issues
+  - /actions/guides/commenting-on-an-issue-when-a-label-is-added
+  - /actions/guides/moving-assigned-issues-on-project-boards
+  - /actions/guides/removing-a-label-when-a-card-is-added-to-a-project-board-column
 
 ---
 <!-- {% link_in_list /about-continuous-integration %} -->
@@ -87,3 +94,11 @@ includeGuides:
 <!-- {% 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 %} -->
+<!-- {% link_in_list /deploying-to-google-kubernetes-engine %} -->
+<!-- {% link_in_list /using-github-actions-for-project-management %} -->
+<!-- {% link_in_list /closing-inactive-issues %} -->
+<!-- {% link_in_list /scheduling-issue-creation %} -->
+<!-- {% link_in_list /adding-labels-to-issues %} -->
+<!-- {% link_in_list /commenting-on-an-issue-when-a-label-is-added %} -->
+<!-- {% link_in_list /moving-assigned-issues-on-project-boards %} -->
+<!-- {% link_in_list /removing-a-label-when-a-card-is-added-to-a-project-board-column %} -->

content/actions/guides/moving-assigned-issues-on-project-boards.md

@@ -0,0 +1,75 @@
+---
+title: Moving assigned issues on project boards
+intro: You can use {% data variables.product.prodname_actions %} to automatically move an issue to a specific column on a project board when the issue is assigned.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+  github-ae: '*'
+type: 'tutorial'
+topics:
+  - 'Workflows'
+  - 'Project management'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+{% data reusables.actions.ae-beta %}
+{% data reusables.actions.ae-self-hosted-runners-notice %}
+
+### Introduction
+
+This tutorial demonstrates how to use the [`alex-page/github-project-automation-plus` action](https://github.com/marketplace/actions/github-project-automation) to automatically move an issue to a specific column on a project board when the issue is assigned. For example, when an issue is assigned, you can move it into the `In Progress` column your project board.
+
+In the tutorial, you will first make a workflow file that uses the [`alex-page/github-project-automation-plus` action](https://github.com/marketplace/actions/github-project-automation). Then, you will customize the workflow to suit your needs.
+
+### Creating the workflow
+
+1. {% data reusables.actions.choose-repo %}
+2. In your repository, choose a project board. You can use an existing project, or you can create a new project. For more information about creating a project, see "[Creating a project board](/github/managing-your-work-on-github/creating-a-project-board)."
+3. {% data reusables.actions.make-workflow-file %}
+4. Copy the following YAML contents into your workflow file.
+
+    {% raw %}
+    ```yaml{:copy}
+    name: Move assigned card
+    on:
+      issues:
+        types:
+          - assigned
+    jobs:
+      move-assigned-card:
+        runs-on: ubuntu-latest
+        steps:
+          - uses: alex-page/github-project-automation-plus@v0.3.0
+            with:
+              project: Docs Work
+              column: In Progress
+              repo-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
+    ```
+    {% endraw %}
+5. Customize the parameters in your workflow file:
+   - Change the value for `project` to the name of your project board. If you have multiple project boards with the same name, the `alex-page/github-project-automation-plus` action will act on all projects with the specified name.
+   - Change the value for `column` to the name of the column where you want issues to move when they are assigned.
+   - Change the value for `repo-token`:
+     1. Create a personal access token with the `repo` scope. For more information, see "[Creating a personal access token](/github/authenticating-to-github/creating-a-personal-access-token)."
+     1. Store this personal access token as a secret in your repository. For more information about storing secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets)."
+     1. In your workflow file, replace `PERSONAL_ACCESS_TOKEN` with the name of your secret.
+6. {% data reusables.actions.commit-workflow %}
+
+### Testing the workflow
+
+Whenever an issue in your repository is assigned, the issue will be moved to the specified project board column. If the issue is not already on the project board, it will be added to the project board.
+
+If your repository is user-owned, the `alex-page/github-project-automation-plus` action will act on all projects in your repository or user account that have the specified project name and column. Likewise, if your repository is organization-owned, the action will act on all projects in your repository or organization that have the specified project name and column.
+
+Test your workflow by assigning an issue in your repository.
+
+1. Open an issue in your repository. For more information, see "[Creating an issue](/github/managing-your-work-on-github/creating-an-issue)."
+2. Assign the issue. For more information, see "[Assigning issues and pull requests to other GitHub users](/github/managing-your-work-on-github/assigning-issues-and-pull-requests-to-other-github-users)."
+3. To see the workflow run that assigning the issue triggered, view the history of your workflow runs. For more information, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
+4. When the workflow completes, the issue that you assigned should be added to the specified project board column.
+
+### Next steps
+
+- To learn more about additional things you can do with the `alex-page/github-project-automation-plus` action, like deleting or archiving project cards, visit the [`alex-page/github-project-automation-plus` action documentation](https://github.com/marketplace/actions/github-project-automation).

content/actions/guides/removing-a-label-when-a-card-is-added-to-a-project-board-column.md

@@ -0,0 +1,75 @@
+---
+title: Removing a label when a card is added to a project board column
+intro: You can use {% data variables.product.prodname_actions %} to automatically remove a label when an issue or pull request is added to a specific column on a project board. 
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+  github-ae: '*'
+type: 'tutorial'
+topics:
+  - 'Workflows'
+  - 'Project management'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+{% data reusables.actions.ae-beta %}
+{% data reusables.actions.ae-self-hosted-runners-notice %}
+
+### Introduction
+
+This tutorial demonstrates how to use the [`andymckay/labeler` action](https://github.com/marketplace/actions/simple-issue-labeler) along with a conditional to remove a label from issues and pull requests that are added to a specific column on a project board. For example, you can remove the `needs review` label when project cards are moved into the `Done` column.
+
+In the tutorial, you will first make a workflow file that uses the [`andymckay/labeler` action](https://github.com/marketplace/actions/simple-issue-labeler). Then, you will customize the workflow to suit your needs.
+
+### Creating the workflow
+
+1. {% data reusables.actions.choose-repo %}
+2. Choose a project that belongs to the repository. This workflow cannot be used with projects that belong to users or organizations. You can use an existing project, or you can create a new project. For more information about creating a project, see "[Creating a project board](/github/managing-your-work-on-github/creating-a-project-board)."
+3. {% data reusables.actions.make-workflow-file %}
+4. Copy the following YAML contents into your workflow file.
+
+    {% raw %}
+    ```yaml{:copy}
+    name: Remove labels
+    on:
+      project_card:
+        types:
+          - moved
+    jobs:
+      remove_labels:
+        if: github.event.project_card.column_id == '12345678'
+        runs-on: ubuntu-latest
+        steps:
+          - name: remove labels
+            uses: andymckay/labeler@master
+            with:
+              remove-labels: "needs review"
+    ```
+    {% endraw %}
+5. Customize the parameters in your workflow file:
+   - In `github.event.project_card.column_id == '12345678'`, replace `12345678` with the ID of the column where you want to un-label issues and pull requests that are moved there.
+
+    To find the column ID, navigate to your project board. Next to the title of the column, click {% octicon "kebab-horizontal" aria-label="The horizontal kebab icon" %} then click **Copy column link**. The column ID is the number at the end of the copied link. For example, `24687531` is the column ID for `https://github.com/octocat/octo-repo/projects/1#column-24687531`.
+
+     If you want to act on more than one column, separate the conditions with `||`. For example, `if github.event.project_card.column_id == '12345678' || github.event.project_card.column_id == '87654321'` will act whenever a project card is added to column `12345678` or column `87654321`. The columns may be on different project boards.
+   - Change the value for `remove-labels` to the list of labels that you want to remove from issues or pull requests that are moved to the specified column(s). Separate multiple labels with commas. For example, `"help wanted, good first issue"`. For more information on labels, see "[Managing labels](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)."
+6. {% data reusables.actions.commit-workflow %}
+
+### Testing the workflow
+
+Every time a project card on a project in your repository moves, this workflow will run. If the card is an issue or a pull request and is moved into the column that you specified, then the workflow will remove the specified labels from the issue or a pull request. Cards that are notes will not be affected.
+
+Test your workflow out by moving an issue on your project into the target column.
+
+1. Open an issue in your repository. For more information, see "[Creating an issue](/github/managing-your-work-on-github/creating-an-issue)."
+2. Label the issue with the labels that you want the workflow to remove. For more information, see "[Managing labels](/github/managing-your-work-on-github/managing-labels#applying-labels-to-issues-and-pull-requests)."
+3. Add the issue to the project column that you specified in your workflow file. For more information, see "[Adding issues and pull requests to a project board](/github/managing-your-work-on-github/adding-issues-and-pull-requests-to-a-project-board)."
+4. To see the workflow run that was triggered by adding the issue to the project, view the history of your workflow runs. For more information, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
+5. When the workflow completes, the issue that you added to the project column should have the specified labels removed.
+
+### Next steps
+
+- To learn more about additional things you can do with the `andymckay/labeler` action, like adding labels or skipping this action if the issue is assigned or has a specific label, visit the [`andymckay/labeler` action documentation](https://github.com/marketplace/actions/simple-issue-labeler).
+- [Search GitHub](https://github.com/search?q=%22uses:+andymckay/labeler%22&type=code) for examples of workflows using this action.

content/actions/guides/scheduling-issue-creation.md

@@ -0,0 +1,89 @@
+---
+title: Scheduling issue creation
+intro: You can use {% data variables.product.prodname_actions %} to create an issue on a regular basis for things like daily meetings or quarterly reviews.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+  github-ae: '*'
+type: 'tutorial'
+topics:
+  - 'Workflows'
+  - 'Project management'
+---
+
+{% data reusables.actions.enterprise-beta %}
+{% data reusables.actions.enterprise-github-hosted-runners %}
+{% data reusables.actions.ae-beta %}
+{% data reusables.actions.ae-self-hosted-runners-notice %}
+
+### Introduction
+
+This tutorial demonstrates how to use the [`imjohnbo/issue-bot` action](https://github.com/marketplace/actions/issue-bot-action) to create an issue on a regular basis. For example, you can create an issue each week to use as the agenda for a team meeting.
+
+In the tutorial, you will first make a workflow file that uses the [`imjohnbo/issue-bot` action](https://github.com/marketplace/actions/issue-bot-action). Then, you will customize the workflow to suit your needs.
+
+### Creating the workflow
+
+1. {% data reusables.actions.choose-repo %}
+2. {% data reusables.actions.make-workflow-file %}
+3. Copy the following YAML contents into your workflow file.
+
+    {% raw %}
+    ```yaml{:copy}
+    name: Weekly Team Sync
+    on:
+      schedule:
+        - cron: 20 07 * * 1
+
+    jobs:
+      create_issue:
+        name: Create team sync issue
+        runs-on: ubuntu-latest
+        steps:
+          - name: Create team sync issue
+            uses: imjohnbo/issue-bot@v3.0
+            with:
+              assignees: "monalisa, doctocat, hubot"
+              labels: "weekly sync, docs-team"
+              title: "Team sync"
+              body: |
+                ### Agenda
+
+                - [ ] Start the recording
+                - [ ] Check-ins
+                - [ ] Discussion points
+                - [ ] Post the recording
+                        
+                ### Discussion Points
+                Add things to discuss below
+
+                - [Work this week](https://github.com/orgs/github/projects/3)
+              pinned: false
+              close-previous: false
+            env:
+              GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+    ```
+    {% endraw %}
+4. Customize the parameters in your workflow file:
+   - Change the value for `on.schedule` to dictate when you want this workflow to run. In the example above, the workflow will run every Monday at 7:20 UTC. For more information about scheduled workflows, see "[Scheduled events](/actions/reference/events-that-trigger-workflows#scheduled-events)."
+   - Change the value for `assignees` to the list of {% data variables.product.prodname_dotcom %} usernames that you want to assign to the issue.
+   - Change the value for `labels` to the list of labels that you want to apply to the issue.
+   - Change the value for `title` to the title that you want the issue to have.
+   - Change the value for `body` to the text that you want in the issue body. The `|` character allows you to use a multi-line value for this parameter.
+   - If you want to pin this issue in your repository, set `pinned` to `true`. For more information about pinned issues, see "[Pinning an issue to your repository](/articles/pinning-an-issue-to-your-repository)."
+   - If you want to close the previous issue generated by this workflow each time a new issue is created, set `close-previous` to `true`. The workflow will close the most recent issue that has the labels defined in the `labels` field. To avoid closing the wrong issue, use a unique label or combination of labels.
+5. {% data reusables.actions.commit-workflow %}
+
+### Expected results
+
+Based on the `schedule` parameter (for example, every Monday at 7:20 UTC), your workflow will create a new issue with the assignees, labels, title, and body that you specified. If you set `pinned` to `true`, the workflow will pin the issue to your repository. If you set `close-previous` to true, the workflow will close the most recent issue with matching labels.
+
+{% data reusables.actions.schedule-delay %}
+
+You can view the history of your workflow runs to see this workflow run periodically. For more information, see "[Viewing workflow run history](/actions/managing-workflow-runs/viewing-workflow-run-history)."
+
+### Next steps
+
+- To learn more about additional things you can do with the `imjohnbo/issue-bot` action, like rotating assignees or using an issue template, see the [`imjohnbo/issue-bot` action documentation](https://github.com/marketplace/actions/issue-bot-action).
+- [Search GitHub](https://github.com/search?q=%22uses%3A+imjohnbo%2Fissue-bot%22&type=code) for examples of workflows using this action.

content/actions/guides/using-github-actions-for-project-management.md

@@ -0,0 +1,40 @@
+---
+title: Using GitHub Actions for project management
+intro: You can use {% data variables.product.prodname_actions %} to automate many of your project management tasks.
+product: '{% data reusables.gated-features.actions %}'
+versions:
+  free-pro-team: '*'
+  enterprise-server: '>=2.22'
+  github-ae: '*'
+type: 'overview'
+topics:
+  - 'Project management'
+---
+
+You can use {% data variables.product.prodname_actions %} to automate your project management tasks by creating workflows. Each workflow contains a series of tasks that are performed automatically every time the workflow runs. For example, you can create a workflow that runs every time an issue is created to add a label, leave a comment, and move the issue onto a project board.
+
+### When do workflows run?
+
+You can configure your workflows to run on a schedule or be triggered when an event occurs. For example, you can set your workflow to run when someone creates an issue in a repository.
+
+Many workflow triggers are useful for automating project management.
+
+- An issue is opened, assigned, or labeled.
+- A comment is added to an issue.
+- A project card is created or moved.
+- A scheduled time.
+
+For a full list of events that can trigger workflows, see "[Events that trigger workflows](/actions/reference/events-that-trigger-workflows)."
+
+### What can workflows do?
+
+Workflows can do many things, such as commenting on an issue, adding or removing labels, moving cards on project boards, and opening issues.
+
+You can learn about using {% data variables.product.prodname_actions %} for project management by following these tutorials, which include example workflows that you can adapt to meet your needs.
+
+- "[Adding labels to issues](/actions/guides/adding-labels-to-issues)"
+- "[Removing a label when a card is added to a project board column](/actions/guides/removing-a-label-when-a-card-is-added-to-a-project-board-column)"
+- "[Moving assigned issues on project boards](/actions/guides/moving-assigned-issues-on-project-boards)"
+- "[Commenting on an issue when a label is added](/actions/guides/commenting-on-an-issue-when-a-label-is-added)"
+- "[Closing inactive issues](/actions/guides/closing-inactive-issues)"
+- "[Scheduling issue creation](/actions/guides/scheduling-issue-creation)"

content/actions/hosting-your-own-runners/about-self-hosted-runners.md

@@ -66,6 +66,10 @@ There are some limits on {% data variables.product.prodname_actions %} usage whe
 {% data reusables.github-actions.usage-api-requests %}
 - **Job matrix** - {% data reusables.github-actions.usage-matrix-limits %}
 
+### Workflow continuity for self-hosted runners
+
+{% data reusables.github-actions.runner-workflow-continuity %}
+
 ### Supported architectures and operating systems for self-hosted runners
 
 The following operating systems are supported for the self-hosted runner application.
@@ -131,7 +135,12 @@ github.com
 api.github.com
 *.actions.githubusercontent.com
 github-releases.githubusercontent.com
+github-registry-files.githubusercontent.com
 codeload.github.com
+*.pkg.github.com
+pkg-cache.githubusercontent.com
+pkg-containers.githubusercontent.com
+pkg-containers-az.githubusercontent.com
 ```
 
 If you use an IP address allow list for your {% data variables.product.prodname_dotcom %} organization or enterprise account, you must add your self-hosted runner's IP address to the allow list. For more information, see "[Managing allowed IP addresses for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-allowed-ip-addresses-for-your-organization#using-github-actions-with-an-ip-allow-list)" or "[Enforcing security settings in your enterprise account](/github/setting-up-and-managing-your-enterprise/enforcing-security-settings-in-your-enterprise-account#using-github-actions-with-an-ip-allow-list)".

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

@@ -114,6 +114,12 @@ outputs:
     description: "Path to results file"
 ```
 
+{% if currentVersion == "github-ae@latest" %}
+### Using the actions included with {% data variables.product.prodname_ghe_managed %}
+
+By default, you can use most of the official {% data variables.product.prodname_dotcom %}-authored actions in {% data variables.product.prodname_ghe_managed %}. For more information, see "[Using actions in {% data variables.product.prodname_ghe_managed %}](/admin/github-actions/using-actions-in-github-ae)."
+{% endif %}
+
 ### Referencing an action in the same repository where a workflow file uses the action
 
 If an action is defined in the same repository where your workflow file uses the action, you can reference the action with either the ‌`{owner}/{repo}@{ref}` or `./path/to/dir` syntax in your workflow file.

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

@@ -26,7 +26,7 @@ This guide explains how to configure security hardening for certain {% data vari
 
 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" or currentVersion == "github-ae@latest" %}, 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.
+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 minimize the 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.
 
 To help prevent accidental disclosure, {% data variables.product.product_name %} uses a mechanism that attempts to redact any secrets that appear in run logs. This redaction looks for exact matches of any configured secrets, as well as common encodings of the values, such as Base64. However, because there are multiple ways a secret value can be transformed, this redaction is not guaranteed. As a result, there are certain proactive steps and good practices you should follow to help ensure secrets are redacted, and to limit other risks associated with secrets:
 
@@ -123,6 +123,24 @@ For example, you can use the audit log to track the `org.update_actions_secret`
 The following tables describe the {% data variables.product.prodname_actions %} events that you can find in the audit log. For more information on using the audit log, see
 "[Reviewing the audit log for your organization](/github/setting-up-and-managing-organizations-and-teams/reviewing-the-audit-log-for-your-organization#searching-the-audit-log)."
 
+{% if currentVersion == "free-pro-team@latest" %}
+#### Events for environments
+
+| Action | Description
+|------------------|-------------------
+| `environment.create_actions_secret` | Triggered when a secret is created in an environment. For more information, see ["Environment secrets](/actions/reference/environments#environment-secrets)."
+| `environment.delete` | Triggered when an environment is deleted. For more information, see ["Deleting an environment](/actions/reference/environments#deleting-an-environment)."
+| `environment.remove_actions_secret` |  Triggered when a secret is removed from an environment. For more information, see ["Environment secrets](/actions/reference/environments#environment-secrets)."
+| `environment.update_actions_secret` | Triggered when a secret in an environment is updated. For more information, see ["Environment secrets](/actions/reference/environments#environment-secrets)."
+{% endif %}
+
+{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@2.21" %}
+#### Events for configuration changes
+| Action | Description
+|------------------|-------------------
+| `repo.actions_enabled` | Triggered when {% data variables.product.prodname_actions %} is enabled for a repository. Can be viewed using the UI. This event is not visible when you access the audit log using the REST API. For more information, see "[Using the REST API](#using-the-rest-api)."
+{% endif %}
+
 #### Events for secret management
 | Action | Description
 |------------------|-------------------
@@ -135,11 +153,15 @@ The following tables describe the {% data variables.product.prodname_actions %}
 
 #### Events for self-hosted runners
 | Action | Description
-|------------------|-------------------
+|------------------|-------------------{% if currentVersion ver_gt "enterprise-server@2.21" %}{% else %}
 | `enterprise.register_self_hosted_runner` | Triggered when a new self-hosted runner is registered. For more information, see "[Adding a self-hosted runner to an enterprise](/actions/hosting-your-own-runners/adding-self-hosted-runners#adding-a-self-hosted-runner-to-an-enterprise)."
-| `enterprise.self_hosted_runner_updated` | Triggered when the runner application is updated. Can be viewed using the REST API and the UI; not visible in the JSON/CSV export. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners#about-self-hosted-runners)."
+| `enterprise.remove_self_hosted_runner` | Triggered when a self-hosted runner is removed.
+| `enterprise.runner_group_runners_updated` | Triggered when a runner group's list of members is updated. For more information, see "[Set self-hosted runners in a group for an organization](/rest/reference/actions#set-self-hosted-runners-in-a-group-for-an-organization)."
+| `enterprise.self_hosted_runner_updated` | Triggered when the runner application is updated. Can be viewed using the REST API and the UI. This event is not included when you export the audit log as JSON data or a CSV file. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners#about-self-hosted-runners)" and "[Reviewing the audit log for your organization](/github/setting-up-and-managing-organizations-and-teams/reviewing-the-audit-log-for-your-organization#exporting-the-audit-log)."{% endif %}
 | `org.register_self_hosted_runner` | Triggered when a new self-hosted runner is registered. For more information, see "[Adding a self-hosted runner to an organization](/actions/hosting-your-own-runners/adding-self-hosted-runners#adding-a-self-hosted-runner-to-an-organization)."
 | `org.remove_self_hosted_runner` | Triggered when a self-hosted runner is removed. For more information, see [Removing a runner from an organization](/actions/hosting-your-own-runners/removing-self-hosted-runners#removing-a-runner-from-an-organization).
+| `org.runner_group_runners_updated` | Triggered when a runner group's list of members is updated. For more information, see "[Set self-hosted runners in a group for an organization](/rest/reference/actions#set-self-hosted-runners-in-a-group-for-an-organization)."
+| `org.runner_group_updated` | Triggered when the configuration of a self-hosted runner group is changed. For more information, see "[Changing the access policy of a self-hosted runner group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#changing-the-access-policy-of-a-self-hosted-runner-group)."
 | `org.self_hosted_runner_updated` | Triggered when the runner application is updated. Can be viewed using the REST API and the UI; not visible in the JSON/CSV export. For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners#about-self-hosted-runners)."
 | `repo.register_self_hosted_runner` | Triggered when a new self-hosted runner is registered. For more information, see "[Adding a self-hosted runner to a repository](/actions/hosting-your-own-runners/adding-self-hosted-runners#adding-a-self-hosted-runner-to-a-repository)."
 | `repo.remove_self_hosted_runner` | Triggered when a self-hosted runner is removed. For more information, see "[Removing a runner from a repository](/actions/hosting-your-own-runners/removing-self-hosted-runners#removing-a-runner-from-a-repository)."
@@ -150,13 +172,13 @@ The following tables describe the {% data variables.product.prodname_actions %}
 |------------------|-------------------
 | `enterprise.runner_group_created` | Triggered when a self-hosted runner group is created. For more information, see "[Creating a self-hosted runner group for an enterprise](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#creating-a-self-hosted-runner-group-for-an-enterprise)."
 | `enterprise.runner_group_removed` | Triggered when a self-hosted runner group is removed. For more information, see "[Removing a self-hosted runner group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#removing-a-self-hosted-runner-group)."
-| `enterprise.runner_group_runner_removed` | Triggered when a self-hosted runner is removed from a group.
+| `enterprise.runner_group_runner_removed` | Triggered when the REST API is used to remove a self-hosted runner from a group.
 | `enterprise.runner_group_runners_added` | Triggered when a self-hosted runner is added to a group. For more information, see "[Moving a self-hosted runner to a group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#moving-a-self-hosted-runner-to-a-group)."
 | `enterprise.runner_group_updated` |Triggered when the configuration of a self-hosted runner group is changed. For more information, see "[Changing the access policy of a self-hosted runner group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#changing-the-access-policy-of-a-self-hosted-runner-group)."
 | `org.runner_group_created` | Triggered when a self-hosted runner group is created. For more information, see "[Creating a self-hosted runner group for an organization](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#creating-a-self-hosted-runner-group-for-an-organization)."
 | `org.runner_group_removed` | Triggered when a self-hosted runner group is removed. For more information, see "[Removing a self-hosted runner group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#removing-a-self-hosted-runner-group)."
 | `org.runner_group_runners_added` | Triggered when a self-hosted runner is added to a group. For more information, see "[Moving a self-hosted runner to a group](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups#moving-a-self-hosted-runner-to-a-group)."
-| `org.runner_group_runner_removed` | Triggered when a self-hosted runner is removed from a group.
+| `org.runner_group_runner_removed` | Triggered when the REST API is used to remove a self-hosted runner from a group. For more information, see "[Remove a self-hosted runner from a group for an organization](/rest/reference/actions#remove-a-self-hosted-runner-from-a-group-for-an-organization)."
 
 #### Events for workflow activities
 

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

@@ -40,7 +40,7 @@ This example workflow uses the [labeler action](https://github.com/actions/label
   ```yaml
   name: Pull request labeler
   on:
-  - pull_request
+  - pull_request_target
   jobs:
     triage:
       runs-on: ubuntu-latest

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

@@ -43,11 +43,7 @@ The following steps occur to trigger a workflow run:
 
 The `schedule` event allows you to trigger a workflow at a scheduled time.
 
-{% note %}
-
-Note: Due to load, the `schedule` event may be delayed 
-
-{% endnote %}
+{% data reusables.actions.schedule-delay %}
 
 #### `schedule`
 
@@ -169,7 +165,9 @@ on:
 
 ### Webhook events
 
-You can configure your workflow to run when webhook events are created on {% data variables.product.product_name %}. Some events have more than one activity type that triggers the event. If more than one activity type triggers the event, you can specify which activity types will trigger the workflow to run. For more information, see "[Webhooks](/webhooks)." 
+You can configure your workflow to run when webhook events are generated on {% data variables.product.product_name %}. Some events have more than one activity type that triggers the event. If more than one activity type triggers the event, you can specify which activity types will trigger the workflow to run. For more information, see "[Webhooks](/webhooks)."
+
+Not all webhook events trigger workflows. For the complete list of available webhook events and their payloads, see "[Webhook events and payloads](/developers/webhooks-and-events/webhook-events-and-payloads)."
 
 #### `check_run`
 
@@ -602,7 +600,7 @@ This event runs in the context of the base of the pull request, rather than in t
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
 | --------------------- | -------------- | ------------ | -------------|
-| [`pull_request`](/webhooks/event-payloads/#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `ready_for_review`<br/>- `locked`<br/>- `unlocked` <br/>- `review_requested` <br/>- `review_request_removed` | Last commit on the PR base branch | PR base branch |
+| [`pull_request_target`](/webhooks/event-payloads/#pull_request) | - `assigned`<br/>- `unassigned`<br/>- `labeled`<br/>- `unlabeled`<br/>- `opened`<br/>- `edited`<br/>- `closed`<br/>- `reopened`<br/>- `synchronize`<br/>- `ready_for_review`<br/>- `locked`<br/>- `unlocked` <br/>- `review_requested` <br/>- `review_request_removed` | Last commit on the PR base branch | PR base branch |
 
 By default, a workflow only runs when a `pull_request_target`'s activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows for more activity types, use the `types` keyword. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/articles/workflow-syntax-for-github-actions#onevent_nametypes)."
 
@@ -725,12 +723,14 @@ on:
 {% 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 |	
+| --------------------- | -------------- | ------------ | -------------|
+| [`workflow_run`](/webhooks/event-payloads/#workflow_run) | - `completed`<br/>- `requested` | Last commit on default branch | Default branch |
+
+{% data reusables.developer-site.limit_workflow_to_activity_types %}
 
 If you need to filter branches from this event, you can use `branches` or `branches-ignore`.
 
-In this example, a workflow is configured to run after the separate “Run Tests” workflow completes.
+In this example, a workflow is configured to run after the separate "Run Tests" workflow completes.
 
 ```yaml
 on:
@@ -744,6 +744,27 @@ on:
 
 {% endif %}
 
+To run a workflow job conditionally based on the result of the previous workflow run, you can use the [`jobs.<job_id>.if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif) or [`jobs.<job_id>.steps[*].if`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif) conditional combined with the `conclusion` of the previous run. For example:
+
+```yaml
+on:
+  workflow_run:
+    workflows: ["Build"]
+    types: [completed]
+
+jobs:
+  on-success:
+    runs-on: ubuntu-latest
+    if: {% raw %}${{ github.event.workflow_run.conclusion == 'success' }}{% endraw %}
+    steps:
+      ...
+  on-failure:
+    runs-on: ubuntu-latest
+    if: {% raw %}${{ github.event.workflow_run.conclusion == 'failure' }}{% endraw %}
+    steps:
+      ...
+```
+
 ### Triggering new workflows using a personal access token
 
 {% 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)."

content/actions/reference/usage-limits-billing-and-administration.md

@@ -8,6 +8,8 @@ versions:
   free-pro-team: '*'
   enterprise-server: '>=2.22'
   github-ae: '*'
+topics:
+  - billing
 ---
 
 {% data reusables.actions.enterprise-beta %}

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

@@ -314,7 +314,6 @@ Available {% data variables.product.prodname_dotcom %}-hosted runner types are:
 
 {% data reusables.github-actions.supported-github-runners %}
 
-{% data reusables.github-actions.ubuntu-runner-preview %}
 {% data reusables.github-actions.macos-runner-preview %}
 
 ##### Example