Merge branch 'main' into patch-3

.github/CODEOWNERS

@@ -32,3 +32,6 @@ package.json @github/docs-engineering
 /contributing/content-model.md @github/docs-content-strategy
 /contributing/content-style-guide.md @github/docs-content-strategy
 /contributing/content-templates.md @github/docs-content-strategy
+
+# Requires review of #actions-oidc-integration, docs-engineering/issues/1506
+content/actions/deployment/security-hardening-your-deployments/** @github/oidc

.github/actions-scripts/check-for-enterprise-issues-by-label.js

@@ -3,17 +3,20 @@
 import { getOctokit } from '@actions/github'
 import { setOutput } from '@actions/core'
 
+const ENTERPRISE_DEPRECATION_LABEL = 'enterprise deprecation'
+const ENTERPRISE_RELEASE_LABEL = 'GHES release tech steps'
+
 async function run() {
   const token = process.env.GITHUB_TOKEN
   const octokit = getOctokit(token)
   const queryDeprecation = encodeURIComponent('is:open repo:github/docs-engineering is:issue')
   const queryRelease = encodeURIComponent('is:open repo:github/docs-content is:issue')
 
   const deprecationIssues = await octokit.request(
-    `GET /search/issues?q=${queryDeprecation}+label:"enterprise%20deprecation"`
+    `GET /search/issues?q=${queryDeprecation}+label:"${encodeURI(ENTERPRISE_DEPRECATION_LABEL)}"`
   )
   const releaseIssues = await octokit.request(
-    `GET /search/issues?q=${queryRelease}+label:"enterprise%20release"`
+    `GET /search/issues?q=${queryRelease}+label:"${encodeURI(ENTERPRISE_RELEASE_LABEL)}"`
   )
   const isDeprecationIssue = deprecationIssues.data.items.length === 0 ? 'false' : 'true'
   const isReleaseIssue = releaseIssues.data.items.length === 0 ? 'false' : 'true'

.github/actions-scripts/create-enterprise-issue.js

@@ -87,8 +87,8 @@ async function run() {
   )
   const issueLabels =
     milestone === 'release'
-      ? ['enterprise release']
-      : ['enterprise deprecation', 'priority-4', 'batch', 'time sensitive']
+      ? ['GHES release tech steps']
+      : ['enterprise deprecation', 'priority-1', 'batch', 'time sensitive']
   const issueTitle = `[${nextMilestoneDate}] Enterprise Server ${versionNumber} ${milestone} (technical steps)`
 
   const issueBody = `GHES ${versionNumber} ${milestone} occurs on ${nextMilestoneDate}.

.github/actions-scripts/enterprise-server-issue-templates/deprecation-issue.md

@@ -1,60 +1,87 @@
 ## Overview
 
-The day after a GHES version's [deprecation date](https://github.com/github/docs-internal/tree/main/lib/enterprise-dates.json), a banner on the docs will say: `This version was deprecated on <date>.` This is all users need to know. However, we don't want to update those docs anymore or link to them in the nav.  Follow the steps in this issue to **archive** the docs.
+The day after a GHES version's [deprecation date](https://github.com/github/docs-internal/tree/main/lib/enterprise-dates.json), a banner on the docs will say: `This version was deprecated on <date>.` This is all users need to know. However, we don't want to update those docs anymore or link to them in the nav. Follow the steps in this issue to **archive** the docs.
 
 **Note**: Do each step below in a separate PR. Only move on to the next step when the previous PR has been merged.
 
+The following large repositories are used throughout this checklist, it may be useful to clone them before you begin:
+
+- `github/help-docs-archived-enterprise-versions`
+- `github/github`
+- `github/docs-internal`
+
+Additionally, you may want to download:
+
+- [Azure Storage Explorer](https://aka.ms/portalfx/downloadstorageexplorer)
+
 ## Step 0: Remove deprecated version numbers from docs-content issue forms
 
-**Note**: This step can be performed independently of all other steps, and can be done several days before or along with the other steps. 
+**Note**: This step can be performed independently of all other steps, and can be done several days before or along with the other steps.
 
 - [ ] In the `docs-content` repo, remove the deprecated GHES version number from the "Specific GHES version(s)" section in the following files (in the `.github/ISSUE_TEMPLATE/` directory): [`release-tier-1-or-2-tracking.yml`](https://github.com/github/docs-content/blob/main/.github/ISSUE_TEMPLATE/release-tier-1-or-2-tracking.yml) and [`release-tier-3-or-tier-4.yml`](https://github.com/github/docs-content/blob/main/.github/ISSUE_TEMPLATE/release-tier-3-or-tier-4.yml).
-- [ ] When the PR is approved, merge it in. This can be merged independently from all other steps. 
+- [ ] When the PR is approved, merge it in. This can be merged independently from all other steps.
 
 ## Step 1: Scrape the docs and archive the files
 
 - [ ] In your checkout of the [repo with archived GHES content](https://github.com/github/help-docs-archived-enterprise-versions), create a new branch: `git checkout -b deprecate-<version>`
 - [ ] In your `docs-internal` checkout, download the static files for the oldest supported version into your archival checkout:
-    The archive script depends on an optional dependency so install optional dependencies first:
-    ```
-    $ npm ci --include-optional
-    ```
-    Then run the archive script:
-    ```
-    $ script/enterprise-server-deprecations/archive-version.js -p <path-to-archive-repo-checkout>
-    ```
-    If your checkouts live in the same directory, this command would be:
-    ```
-    $ script/enterprise-server-deprecations/archive-version.js -p ../help-docs-archived-enterprise-versions
-    ```
-    **Note:** You can pass the `--dry-run` flag to scrape only the first 10 pages plus their redirects for testing purposes.
-  
+      The archive script depends on an optional dependency so install optional dependencies first:
+  ```
+  $ npm i --include-optional
+  ```
+  Ensure your build is up to date:
+  ```
+  $ npm run build
+  ```
+  Then run the archive script:
+  ```
+  $ script/enterprise-server-deprecations/archive-version.js -p <path-to-archive-repo-checkout>
+  ```
+  If your checkouts live in the same directory, this command would be:
+  ```
+  $ script/enterprise-server-deprecations/archive-version.js -p ../help-docs-archived-enterprise-versions
+  ```
+  **Note:** You can pass the `--dry-run` flag to scrape only the first 10 pages plus their redirects for testing purposes. **If you use the dry run command, be sure to run the full script without `--dry-run` before you commit the changes.**
+
 ## Step 2: Upload the assets directory to Azure storage
 
 - [ ] Log in to the Azure portal from Okta. Navigate to the [githubdocs Azure Storage Blob resource](https://portal.azure.com/#@githubazure.onmicrosoft.com/resource/subscriptions/fa6134a7-f27e-4972-8e9f-0cedffa328f1/resourceGroups/docs-production/providers/Microsoft.Storage/storageAccounts/githubdocs/overview).
-- [ ] Click the "Open in Explorer" button to the right of search box.If you haven't already, click the download link to download "Microsoft Azure Storage Explorer." To login to the app, click the plug icon in the left sidebar and click the option to "add an azure account." When you login, you'll need a yubikey to authenticate through Okta.
-- [ ] From the Microsoft Azure Storage Explorer app, select the `githubdocs` storage account resource and navigate to the `github-images` blob container. 
-- [ ] Click "Upload" and select "Upload folder." Click the "Selected folder" input to navigate to the `help-docs-archived-enterprise-versions` repository and select the `assets` directory for the version you just generated. In the "Destination folder" input, add the version number. For example, `/enterprise/2.22/`.
+- [ ] Click the "Open in Explorer" button to the right of search box. If you haven't already, click the download link to download "Microsoft Azure Storage Explorer." To login to the app, click the plug icon in the left sidebar and click the option to "add an azure account." When you login, you'll need a yubikey to authenticate through Okta.
+- [ ] From the Microsoft Azure Storage Explorer app, select the `githubdocs` storage account resource and navigate to the `github-images` blob container.
+- [ ] Click "Upload" and select "Upload folder." Click the "Selected folder" input to navigate to the `help-docs-archived-enterprise-versions` repository and select the `assets` directory for the version you just generated. In the "Destination directory" input, add the version number. For example, `/enterprise/2.22/`.
 - [ ] Check the log to ensure all files were uploaded successfully.
-- [ ] Remove the `assets` directory from your `help-docsc-archived-enterprise-versions` repository, we don't want to commit that directory in the next step.
+- [ ] Remove the `assets` directory from your `help-docs-archived-enterprise-versions` repository, we don't want to commit that directory in the next step.
 
 ## Step 3: Commit and push changes to help-docs-archived-enterprise-versions repo
 
-- [ ] Search for `site-search-input` in the compressed Javascript files (should find the file in the `_next` directory). When you find it, use something like https://beautifier.io/ to reformat it to be readable. Find `site-search-input` in the file, the result will be enclosed in a function that looks something like... `1125: function () { ... },` Delete the innards of this function, but leave the `function() {}` part.
-- [ ] Copy, paste, and save the updated file back into your local `help-docs-archived-enterprise-versions` repository.
+- [ ] Search for `site-search-input` in the compressed Javascript files (should find the file in the `_next` directory). When you find it, use something like https://beautifier.io/ or VSCode to reformat it to be readable. To reformat using VSCode, use the "Format document" option or <kbd>Shift</kbd>+<kbd>Option</kbd>+<kbd>F</kbd>. Find `site-search-input` in the file, the result will be enclosed in a function that looks something like... `1125: function () { ... },` Delete the innards of this function, but leave the `function() {}` part.
+- [ ] Save the file. If using beautifier, copy and paste the updated file back into your local `help-docs-archived-enterprise-versions` repository.
 - [ ] In your archival checkout, `git add <version>`, commit, and push.
 - [ ] Open a PR and merge it in. Note that the version will _not_ be deprecated on the docs site until you do the next step.
 
 ## Step 4: Deprecate the version in docs-internal
 
 In your `docs-internal` checkout:
+
 - [ ] Create a new branch: `git checkout -b deprecate-<version>`.
-- [ ] Edit `lib/enterprise-server-releases.js` by removing the version number to be deprecated from the `supported` array and move it to the `deprecated` array.
+- [ ] Edit `lib/enterprise-server-releases.js` by removing the version number to be deprecated from the `supported` array and move it to the `deprecatedWithFunctionalRedirects` array.
+
+## Test that the archived static pages were generated correctly
+
+You can test that the static pages were generated correctly on localhost and on staging. Verify that the static pages are accessible by running `npm run dev` in your local `docs-internal` checkout and navigate to:
+`http://localhost:3000/enterprise/<version>/`.
+
+Note: the GitHub Pages deployment from the previous step will need to have completed successfully in order for you to test this. You may need to wait up to 10 minutes for this to occur.
+
+Poke around several pages, ensure that the stylesheets are working properly, images are rendering properly, and that the search functionality was disabled.
+
+## Step 5: Continue to deprecate the version in docs-internal
+
 - [ ] Open a new PR. Make sure to check the following:
-    - [ ] Tests are passing (you may need to include the changes in step 6 to get tests to pass).
-    - [ ] The deprecated version renders in preview as expected. You should be able to navigate to `docs.github.com/enterprise/<DEPRECATED VERSION>` to access the docs. You should also be able to navigate to a page that is available in the deprecated version and change the version in the URL to the deprecated version, to test redirects.
-    - [ ] The new oldest supported version renders on staging as expected. You should see a banner on the top of every page for the oldest supported version that notes when the version will be deprecated.
-    
+  - [ ] Tests are passing (you may need to include the changes in step 6 to get tests to pass).
+  - [ ] The deprecated version renders in preview as expected. You should be able to navigate to `docs.github.com/enterprise/<DEPRECATED VERSION>` to access the docs. You should also be able to navigate to a page that is available in the deprecated version and change the version in the URL to the deprecated version, to test redirects.
+  - [ ] The new oldest supported version renders on staging as expected. You should see a banner on the top of every page for the oldest supported version that notes when the version will be deprecated.
+
 ## Step 5: Remove static files for the version
 
 - [ ] In your `docs-internal` checkout, create a new branch `remove-<version>-static-files` branch: `git checkout -b remove-<version>-static-files` (you can branch off of `main` or from your `deprecate-<version>` branch, up to you).
@@ -67,16 +94,16 @@ In your `docs-internal` checkout:
 
 - [ ] In your `docs-internal` checkout, create a new branch `remove-<version>-markup` branch: `git checkout -b remove-<version>-markup` (you can branch off of `main` or from your `deprecate-<version>` branch, up to you).
 - [ ] Remove the outdated Liquid markup and frontmatter.
-    - [ ] Run the script: `script/enterprise-server-deprecations/remove-version-markup.js --release <number>`.
-    - [ ] Spot check a few changes. Content, frontmatter, and data files should all have been updated.
-    - [ ] Open a PR with the results. The diff may be large and complex, so make sure to get a review from `@github/docs-content`.
-    - [ ] Debug any test failures or unexpected results -- it's very likely manual updates will be necessary, the script does a lot of work but doesn't automate everything and can't 100% replace human intent.
-- [ ] When the PR is approved, merge it in to complete the deprecation. This can be merged independently from step 5. 
+  - [ ] Run the script: `script/enterprise-server-deprecations/remove-version-markup.js --release <number>`.
+  - [ ] Spot check a few changes. Content, frontmatter, and data files should all have been updated.
+  - [ ] Open a PR with the results. The diff may be large and complex, so make sure to get a review from `@github/docs-content`.
+  - [ ] Debug any test failures or unexpected results -- it's very likely manual updates will be necessary, the script does a lot of work but doesn't automate everything and can't 100% replace human intent.
+- [ ] When the PR is approved, merge it in to complete the deprecation. This can be merged independently from step 5.
 
 ## Step 7: Deprecate the OpenAPI description in `github/github`
-    
+
 - [ ] In `github/github`, edit the release's config file in `app/api/description/config/releases/`, and change `deprecated: false` to `deprecated: true`.
 - [ ] Open a new PR, and get the required code owner approvals. A docs-content team member can approve it for the docs team.
-- [ ] When the PR is approved, [deploy the `github/github` PR](https://thehub.github.com/engineering/devops/deployment/deploying-dotcom/).  If you haven't deployed a `github/github` PR before, work with someone that has -- the process isn't too involved depending on how you deploy, but there are a lot of details that can potentially be confusing as you can see from the documentation.
+- [ ] When the PR is approved, [deploy the `github/github` PR](https://thehub.github.com/epd/engineering/devops/deployment/deploying-dotcom/). If you haven't deployed a `github/github` PR before, work with someone that has -- the process isn't too involved depending on how you deploy, but there are a lot of details that can potentially be confusing as you can see from the documentation.
 
-**Note**: you can do this step independently of the other steps after a GHES version is deprecated since it should no longer get updates in github/github.  You should plan to get this PR merged as soon as possible, otherwise if you wait too long our OpenAPI automation may re-add the static files that you removed in step 5.
+**Note**: you can do this step independently of the other steps after a GHES version is deprecated since it should no longer get updates in github/github. You should plan to get this PR merged as soon as possible, otherwise if you wait too long our OpenAPI automation may re-add the static files that you removed in step 5.

.github/actions-scripts/msft-create-translation-batch-pr.js

@@ -119,7 +119,7 @@ async function main() {
     title: TITLE,
     base: BASE,
     head: HEAD,
-    body: `New translation batch for ${LANGUAGE}. You can see the log in [\`translations/log/${LANGUAGE}-resets.csv\`](https://github.com/${OWNER}/${REPO}/tree/${HEAD}/translations/log/${LANGUAGE}-resets.csv).`,
+    body: `New translation batch for ${LANGUAGE}. You can see the log in [\`translations/log/${LANGUAGE}-resets.csv\`](https://github.com/${OWNER}/${REPO}/tree/${HEAD}/translations/log/msft-${LANGUAGE}-resets.csv).`,
     labels: ['translation-batch', `translation-batch-${LANGUAGE}`],
     owner: OWNER,
     repo: REPO,

.github/workflows/azure-preview-env-deploy.yml

@@ -17,6 +17,7 @@ on:
   # unlike 'pull_request_target', these only have secrets if the pull
   # request creator has permission to access secrets.
   pull_request_target:
+  merge_group:
   workflow_dispatch:
     inputs:
       PR_NUMBER:
@@ -27,9 +28,6 @@ on:
         description: 'The commit SHA to build'
         type: string
         required: true
-  push:
-    branches:
-      - gh-readonly-queue/main/**
 
 permissions:
   contents: read
@@ -200,7 +198,7 @@ jobs:
       - name: Run ARM deploy
         # This 'if' will be truth, if this workflow is...
         #  - run as a workflow_dispatch
-        #  - run because of a push to main (or gh-readonly-queue/main)
+        #  - run because of a push to main (or when added to a merge queue)
         #  - run as a regular pull request
         # But if it's a pull request, *and* for whatever reason, the pull
         # request has "Auto-merge" enabled, don't bother.

.github/workflows/azure-prod-build-deploy.yml

@@ -150,6 +150,11 @@ jobs:
           FASTLY_SURROGATE_KEY: 'every-deployment'
         run: npm install got && .github/actions-scripts/purge-fastly-edge-cache.js
 
+  send-slack-notification-on-failure:
+    needs: [azure-prod-build-and-deploy]
+    runs-on: ubuntu-latest
+    if: ${{ failure() }}
+    steps:
       - name: Send Slack notification if workflow failed
         uses: someimportantcompany/github-actions-slack-message@f8d28715e7b8a4717047d23f48c39827cacad340
         if: ${{ failure() }}

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

@@ -52,8 +52,6 @@ jobs:
         env:
           NODE_ENV: production
           PORT: 4000
-          DISABLE_OVERLOAD_PROTECTION: true
-          DISABLE_RENDERING_CACHE: true
           # We don't want or need the changelog entries in this context.
           CHANGELOG_DISABLED: true
           # The default is 10s. But because this runs overnight, we can
@@ -62,7 +60,7 @@ jobs:
           # Don't care about CDN caching image URLs
           DISABLE_REWRITE_ASSET_URLS: true
         run: |
-          node server.mjs > /tmp/stdout.log 2> /tmp/stderr.log &
+          node server.js > /tmp/stdout.log 2> /tmp/stderr.log &
           sleep 6
           curl --retry-connrefused --retry 5 -I http://localhost:4000/