Merge branch 'main' into refresh-around-dependencies-#15750

Author: mchammer01

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

@@ -15,6 +15,11 @@ The day after a GHES version's [deprecation date](https://github.com/github/docs
 
 - [ ] 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>
     ```
@@ -26,52 +31,52 @@ The day after a GHES version's [deprecation date](https://github.com/github/docs
   
 ## Step 2: Upload the assets directory to Azure storage
 
-- [ ] Log in to the Azure portal from Okta. Navigate to the [githubdocs Azure Storage Blob resoruce](https://portal.azure.com/#@githubazure.onmicrosoft.com/resource/subscriptions/fa6134a7-f27e-4972-8e9f-0cedffa328f1/resourceGroups/docs-production/providers/Microsoft.Storage/storageAccounts/githubdocs/overview).
+- [ ] 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/`.
 - [ ] Check the log to ensure all files were uploaded successfully.
-- [ ] Removed the `assets` directory from the `/help-docsc-archived-enterprise-versions` repository.
+- [ ] Remove the `assets` directory from your `help-docsc-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. When you find it, use something like https://beautifier.io/ to reformat it to be readable. Find `site-search-input` in the file, there will be something like... `1125: function () { return [SearchReactComponent] },` Delete the innards of this function, but leave the `function() {}` part.
+- [ ] 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.
 - [ ] 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 moving the number to be deprecated into 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 `deprecated` array.
 - [ ] Open a new PR. Make sure to check the following:
-    - [ ] Tests are passing.
-    - [ ] The deprecated version renders on staging 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.
+    - [ ] 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.
     
-You may need to include the changes in step 6 to get tests to pass.
-
 ## Step 5: Remove static files for the version
 
-- [ ] In your `docs-internal` checkout, from your `remove-<version>-static-files` branch: `git checkout -b remove-<version>-static-files`
+- [ ] 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).
 - [ ] Run `script/enterprise-server-deprecations/remove-static-files.js` and commit results.
 - [ ] Run `script/enterprise-server-deprecations/remove-redirects.js` and commit results.
-- [ ] `lib/rest/static` directory has deferenced and decorated directory underneath, remove the numbered version and all below from the list
 - [ ] Open a new PR.
 - [ ] Get a review from docs-engineering and merge. This step can be merged independently from step 6. The purpose of splitting up steps 5 and 6 is to focus the review on specific files.
 
 ## Step 6: Remove the liquid conditionals and content for the version
 
-- [ ] In your `docs-internal` checkout, from your `remove-<version>-markup` branch: `git checkout -b remove-<version>-markup`
+- [ ] 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. 
+    - [ ] 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, merge the `github/github` PR.
+- [ ] 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.
+
+**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/enterprise-server-issue-templates/release-issue.md

@@ -98,26 +98,37 @@ This file should be automatically updated, but you can also run `script/update-e
 
 ### Before shipping the release branch
 
-- [ ] Add the GHES release notes to `data/release-notes/` and update the versioning frontmatter in `content/admin/release-notes.md` to `enterprise-server: '<=<RELEASE>'`
+- [ ] Add the GHES release notes to `data/release-notes/`.
 - [ ] Add any required smoke tests to the opening post in the megabranch PR.
 
   Usually, we should smoke test any new GHES admin guides, any large features landing in this GHES version for the first time, and the REST and GraphQL API references.
-- [ ] Alert the Neon Squad (formally docs-ecosystem team)  1-2 days before the release to deploy to `github/github`. A PR should already be open in `github/github`, to change `published` to `true` in  `app/api/description/config/releases/ghes-<NEXT RELEASE NUMBER>.yaml`. They will need to:
+- [ ] A few days before shipping, check for broken links. Run `script/check-english-links.js` in a local copy of the megabranch.
+- [ ] [Freeze the repos](https://github.com/github/docs-content/blob/main/docs-content-docs/docs-content-workflows/freezing.md) at least 1-2 days before the release, and post an announcement in Slack so everybody knows. It's helpful to freeze the repos before doing the OpenAPI merges to avoid changes to the megabranch while preparing and deploying.
+- [ ] Alert the Neon Squad (formally docs-ecosystem team)  1-2 days before the release to deploy to `github/github`. A PR should already be open in `github/github`, to change the OpenAPI schema config `published` to `true` in `app/api/description/config/releases/ghes-<NEXT RELEASE NUMBER>.yaml`. They will need to:
   - [ ] Get the required approval from `@github/ecosystem-api-reviewers` then deploy the PR to dotcom. This process generally takes 30-90 minutes.
-  - [ ] Once the PR merges, make sure that the auto-generated PR titled "Update OpenAPI Descriptions" in doc-internal contains both the derefrenced and decorated JSON files for the new GHES release. If everything looks good, merge the "Update OpenAPI Description" PR into the GHES release megabranch. **Note:** Be careful about resolving the conflicts correctly—you may wish to delete the existing OpenAPI files for the release version from the megabranch, so there are no conflicts to resolve and to ensure that the incoming artifacts are the correct ones.
-  - [ ] Add a blocking review to the auto-generated "Update OpenAPI Descriptions" PR in the public REST API description. (Remove this blocking review once the GHES release ships.)
-- [ ] [Freeze the repos](https://github.com/github/docs-content/blob/main/docs-content-docs/docs-content-workflows/freezing.md) at least 1-2 days before the release, and post an announcement in Slack so everybody knows.
+  - [ ] Once the PR merges, make sure that the auto-generated PR titled "Update OpenAPI Descriptions" in doc-internal contains both the dereferenced and decorated JSON files for the new GHES release. If everything looks good, merge the "Update OpenAPI Description" PR into the GHES release megabranch. **Note:** Be careful about resolving the conflicts correctly—you may wish to delete the existing OpenAPI files for the release version from the megabranch (that is, delete the GHES release version `lib/rest/static` decorated and dereferenced JSON files), so there are no conflicts to resolve and to ensure that the incoming artifacts are the correct ones.
+- [ ] Alert the Ecosystem-API team in #ecosystem-api about the pending release freeze and incoming blocking review of OpenAPI updates in the public REST API description (the `rest-api-descriptions` repo). They'll need to block any future "Update OpenAPI Descriptions" PRs in the public REST API description until after the ship.
+  - [ ] Add a blocking review to the auto-generated "Update OpenAPI Descriptions" PR in the public REST API description. (You or they will remove this blocking review once the GHES release ships.)
+
 
 ### 🚢 🛳️ 🚢 Shipping the release branch
 
 - [ ] Remove `[DO NOT MERGE]` and other meta information from the PR title 😜.
 - [ ] The `github/docs-internal` repo is frozen, and the `Repo Freeze Check / Prevent merging during deployment freezes (pull_request_target)` test is expected to fail.
 
   Use admin permissions to ship the release branch with this failure. Make sure that the merge's commit title does not include anything like `[DO NOT MERGE]`, and remove all the branch's commit details from the merge's commit message except for the co-author list.
-- [ ] Do any required smoke tests listed in the opening post in the megabranch PR.
+- [ ] Do any required smoke tests listed in the opening post in the megabranch PR. You can monitor and check when the production deploy completed by viewing the [`docs-internal` deployments page](https://github.com/github/docs-internal/deployments).
 - [ ] Once smoke tests have passed, you can [unfreeze the repos](https://github.com/github/docs-content/blob/main/docs-content-docs/docs-content-workflows/freezing.md) and post an announcement in Slack.
-- [ ] After unfreezing, push the search index LFS objects for the public `github/docs` repo. The LFS objects were already being pushed for the internal repo after the `sync-english-index-for-<PLAN@RELEASE>` was added to the megabranch. To push the LFS objects, run the [search sync workflow](https://github.com/github/docs-internal/actions/workflows/sync-search-indices.yml) with the following inputs:
-  version: `enterprise-server@<RELEASE>`
-  language: `en`
+- [ ] After unfreezing, the megabranch creator should push the search index LFS objects for the public `github/docs` repo. The LFS objects were already pushed for the internal repo after the `sync-english-index-for-<PLAN@RELEASE>` was added to the megabranch. To push the LFS objects to the public repo:
+  1. First navigate to the [sync search indices workflow](https://github.com/github/docs-internal/actions/workflows/sync-search-indices.yml). 
+  2. Then, to run the workflow with parameters, click on `Run workflow` button. 
+  3. A modal will pop up where you will set the following inputs:
+     - Branch: The new version megabranch you're working on
+     - Version: `enterprise-server@<RELEASE>`
+     - Language: `en`
+  4. Run the job. The workflow job may fail on the first run—so retry the failed job if needed.
+- [ ] After unfreezing, alert the Ecosystem-API team in #ecosystem-api the docs freeze is finished/thawed and the release has shipped. 
+  - [ ] You (or they) can now remove your blocking review on the auto-generated "Update OpenAPI Descriptions" PR in public REST API description (the `rest-api-descriptions` repo). (although it's likely newer PRs have been created since yours with the blocking review, in which case the Ecosystem-API team will close your PR and perform the next step on the most recent PR).
+  - [ ] The Ecosystem-API team will merge the latest auto-generated "Update OpenAPI Descriptions" PR (which will contain the OpenAPI schema config that changed `published` to `true` for the release).
 - [ ] After unfreezing, if there were significant or highlighted GraphQL changes in the release, consider manually running the [GraphQL update workflow](https://github.com/github/docs-internal/actions/workflows/update-graphql-files.yml) to update our GraphQL schemas. By default this workflow only runs once every 24 hours.
 - [ ] After the release, in the `docs-content` repo, add the now live version number to the "Specific GHES version(s)" section in the following files: [`.github/ISSUE_TEMPLATE/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 [`.github/ISSUE_TEMPLATE/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. 

.github/actions-scripts/openapi-schema-branch.js

@@ -36,7 +36,7 @@ const changedFiles = execSync('git diff --name-only HEAD').toString()
 if (changedFiles !== '') {
   console.log(`These files were changed:\n${changedFiles}`)
   console.log(
-    `🚧⚠️ Your decorated and dereferenced schema files don't match. Ensure you're using decorated and dereferenced schemas from the automatically created pull requests by the 'github-openapi-bot' user. \n\n If this test is failing after updates to the script/rest directory, run script/rest/update-files.js --decorate-only to re-generate the decorated files from the existing dereferenced files and check those in. \n\n If this test is failing after an update to a package, check the changes the new package makes to the decorated files by running script/rest/update-files.js --decorate-only. If the changes are small style changes that don't impact the overall experience, check the updated decorated file in. Otherwise, more work may be needed to be compatible with the updated package. \n\n For more information, see 'script/rest/README.md'. 🛑`
+    `🚧⚠️ Your decorated and dereferenced schema files don't match. Ensure you're using decorated and dereferenced schemas from the automatically created pull requests by the 'github-openapi-bot' user. \n\n If this test is failing after updates to the script/rest directory, run script/rest/update-files.js --decorate-only to re-generate the decorated files from the existing dereferenced files and check those in. \n\n If this test is failing after an update to a package, check the changes the new package makes to the decorated files by running script/rest/update-files.js --decorate-only.\n\nIf you updated script/rest/utils/rest-api-overrides.json, you'll need to run script/rest/update-files.js --decorate-only to regenerate the decorated file and redirects file (check in the changed lib/rest/static/decorated files).\n\nIf the changes are small style changes that don't impact the overall experience, check the updated decorated file in. Otherwise, more work may be needed to be compatible with the updated package. \n\n For more information, see 'script/rest/README.md'. 🛑`
   )
   process.exit(1)
 }

.github/actions-scripts/prune-for-preview-env.sh

@@ -20,5 +20,4 @@ mkdir translations
 # front-matter will be at play.
 # These static redirects json files are notoriously large
 echo '[]' > lib/redirects/static/archived-frontmatter-fallbacks.json
-echo '{}' > lib/redirects/static/developer.json
 echo '{}' > lib/redirects/static/archived-redirects-from-213-to-217.json

.github/dependabot.yml

@@ -3,7 +3,8 @@ updates:
   - package-ecosystem: npm
     directory: '/'
     schedule:
-      interval: monthly
+      interval: weekly
+      day: tuesday
     open-pull-requests-limit: 20 # default is 5
     ignore:
       - dependency-name: '*'
@@ -13,7 +14,8 @@ updates:
   - package-ecosystem: 'github-actions'
     directory: '/'
     schedule:
-      interval: monthly
+      interval: weekly
+      day: wednesday
     ignore:
       - dependency-name: '*'
         update-types:
@@ -22,8 +24,5 @@ updates:
   - package-ecosystem: 'docker'
     directory: '/'
     schedule:
-      interval: monthly
-    ignore:
-      - dependency-name: '*'
-        update-types:
-          ['version-update:semver-patch', 'version-update:semver-minor']
+      interval: weekly
+      day: thursday

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

@@ -17,7 +17,7 @@ jobs:
     if: github.repository == 'github/docs-internal' || github.repository == 'github/docs'
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/stale@7fb802b3079a276cf3c7e6ba9aa003c665b3f838
+      - uses: actions/stale@3cc123766321e9f15a6676375c154ccffb12a358
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
           stale-issue-message: 'This issue is stale because it has been open 60 days with no activity.'