jprdonnelly/docs
1
0
Fork 0
mirror of synced 2025-12-30 03:01:36 -05:00
Code Issues Projects Releases Wiki Activity

Create ghes release features (#36718)

Browse Source
This commit is contained in:
Rachael Sewell
2023-05-01 08:57:38 -07:00
committed by GitHub
parent 2876eda1f9
commit 7c7ec9027e
32 changed files with 116 additions and 175 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
.github/actions-scripts/create-enterprise-issue.js vendored
View File

@@ -5,7 +5,7 @@ import path from 'path'
import { getOctokit } from '@actions/github'
import { latest, oldestSupported } from '../../lib/enterprise-server-releases.js'
const enterpriseDates = JSON.parse(
await fs.readFile(path.join(process.cwd(), 'lib/enterprise-dates.json'))
await fs.readFile(path.join(process.cwd(), 'src/ghes-releases/lib/enterprise-dates.json'))
)
const acceptedMilestones = ['release', 'deprecation']
@@ -23,7 +23,8 @@ const numberOfdaysBeforeDeprecationToOpenIssue = 15
//
// When a milestone is within the specified number of days, a new issue is
// created using the templates in
// .github/actions-scripts/enterprise-server-issue-templates.
// src/ghes-releases/lib/release-steps.md
// and src/ghes-releases/lib/deprecation-steps.md.
//
// Release issues are then added to the docs content squad board for triage.
// Deprecations issues are owned by docs engineering and are added to the
@@ -53,7 +54,7 @@ async function run() {
if (!versionNumber) {
console.log(
`Could not find the next version number after ${latest} in enterprise-dates.json. Try running script/update-enterprise-dates.js, then rerun this script.`
`Could not find the next version number after ${latest} in enterprise-dates.json. Try running src/ghes-releases/scripts/update-enterprise-dates.js, then rerun this script.`
)
process.exit(0)
}
@@ -62,7 +63,7 @@ async function run() {
if (!datesForVersion) {
console.log(
`Could not find ${versionNumber} in enterprise-dates.json. Try running script/update-enterprise-dates.js, then rerun this script.`
`Could not find ${versionNumber} in enterprise-dates.json. Try running src/ghes-releases/scripts/update-enterprise-dates.js, then rerun this script.`
)
process.exit(0)
}
@@ -79,10 +80,7 @@ async function run() {
}
const milestoneSteps = await fs.readFile(
path.join(
process.cwd(),
`.github/actions-scripts/enterprise-server-issue-templates/${milestone}-issue.md`
),
path.join(process.cwd(), `src/ghes-releases/lib/${milestone}-steps.md`),
'utf8'
)
const issueLabels =

165
.github/actions-scripts/enterprise-server-issue-templates/deprecation-issue.md vendored
View File

@@ -1,165 +0,0 @@
## 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.
**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/github`
- `github/docs-internal`
Additionally, 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.
- [ ] In the `docs-content` repo, remove the deprecated GHES version number from the `options` list in [`release-tracking.yml`](https://github.com/github/docs-content/blob/main/.github/ISSUE_TEMPLATE/release-tracking.yml).
- [ ] 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 `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 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
```
This will generate a directory in `github/docs-internal` called `tmpArchivalDir_<VERSION_TO_DEPRECATE>`. For example 'tmpArchivalDir_3.0'. You can also create a specific output directory using the `--output` flag.
**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: Manually remove the search input from the archived docs
- [ ] 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... `(0,f.jsx)("input",{"data-testid":"site-search-input",` Delete the entire function. For example, this:
```
(0, f.jsxs)("label", {
className: "text-normal width-full",
children: [(0, f.jsx)("span", {
className: "visually-hidden",
"aria-label": R($ || ($ = (0, k.Z)(["label"]))),
"aria-describedby": R(W || (W = (0, k.Z)(["description"]))),
children: R(U || (U = (0, k.Z)(["placeholder"])))
}), (0, f.jsx)("input", {
"data-testid": "site-search-input",
ref: I,
className: h()(pe().searchInput, 24 === p && pe().searchIconBackground24, 24 === p && "form-control px-6 f4", 16 === p && pe().searchIconBackground16, 16 === p && "form-control px-5 f4", "compact" === i && "py-2", "expanded" === i && "py-3", r && pe().searchInputHeader, !r && "width-full", r && j && pe().searchInputExpanded, r && j && "position-absolute top-0 right-0"),
type: "search",
placeholder: R(G || (G = (0, k.Z)(["placeholder"]))),
autoComplete: _ ? "on" : "off",
autoCorrect: "off",
autoCapitalize: "off",
spellCheck: "false",
maxLength: 512,
onChange: function(e) {
S(e.target.value)
},
value: _,
"aria-label": R(K || (K = (0, k.Z)(["label"]))),
"aria-describedby": R(J || (J = (0, k.Z)(["description"])))
})
```
becomes:
```
(0, f.jsxs)('label', {
className: 'text-normal width-full',
children: [
(0, f.jsx)('span', {
className: 'visually-hidden',
'aria-label': y(Q || (Q = (0, k.Z)(['label']))),
'aria-describedby': y(X || (X = (0, k.Z)(['description']))),
children: y(ee || (ee = (0, k.Z)(['placeholder']))),
}),
],
}),
```
- [ ] Save the file. If using beautifier, copy and paste the updated file back into your temp directory with the scraped archive content.
## Step 3: Upload the scraped content 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 `enterprise` blob container.
- [ ] Click "Upload" and select "Upload folder." Click the "Selected folder" input to navigate to the temp directory you just generated. Inside that temp directory, select the `<VERSION_TO_DEPRECATE>` directory (e.g., `3.2`). Leave the destination directory input blank.
- [ ] Check the log to ensure all files were uploaded successfully.
- [ ] Remove the temporarily created directory from your `github/docs-internal` checkout.
## Step 4: Create a tag and long-running branch
Create a new tag for the most recent commit on the `main` branch so that we can keep track of where in commit history we removed the GHES release. Create a tag called `enterprise-<release number>-release`. Then from that commit on `main` create a new branch called `enterprise-<release number>-release`. This branch will be long-lived and used to rerender and scrape content that is added after a release is deprecated.
## Step 5: 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 `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>/`.
Poke around several pages, ensure that the stylesheets are working properly, images are rendering properly, and that the search functionality was disabled.
## Step 6: Remove static files for the version
**Note:** We do not remove the old content for GHES release notes. New release notes can be added after we perform a deprecation in some rare cases, and not removing this content makes it easier for us to re-scrape the content to add to Azure Blob Storage.
- [ ] 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.
- [ ] Re-generate the static files by running `src/rest/scripts/update-files.js --decorate-only`.
- [ ] 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 7: Remove the liquid conditionals and content for the version
- [ ] 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.
## Step 8: 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/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.
## Step 9: 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.
## Re-scraping a page or all pages
Occasionally, a change will need to be added to our archived enterprise versions. If this occurs, you can check out the `enterprise-<release number>-release` branch and re-scrape the page or all pages using `script/enterprise-server-deprecations/archive-version.js`. To scrape a single page you can use the `—page <page relative path>` option.
For each language, upload the new file to Azure blob storage in the `enterprise` container.
After uploading the new files, you will need to purge the Fastly cache for the single page. From Okta, go to Fastly and select `docs`. Click `Purge` then `Purge URL`. If you need to purge a whole path, just do a `Purge All`
![](/contributing/images/fastly_purge.jpg)
Enter the URL or path and do a soft purge.
![](/contributing/images/fastly_purge_url.jpg)

327
.github/actions-scripts/enterprise-server-issue-templates/release-issue.md vendored
View File

@@ -1,327 +0,0 @@
**Maintaining this template:** If you notice that any of these steps become out-of-date, open a pull request to update this [issue template](https://github.com/github/docs-internal/blob/main/.github/actions-scripts/enterprise-server-issue-templates/release-issue.md).
## To enable the new version
**Do these steps in a local checkout to create a GHES release branch with passing tests:**
If you aren't comfortable going through the steps alone, sync up with a docs engineer to pair with.
- [ ] Create a new branch from `main` with the name `ghes-<RELEASE>-megabranch`. e.g. `ghes-3.2-megabranch`.
- [ ] In [lib/enterprise-server-releases.js](https://github.com/github/docs-internal/blob/main/lib/enterprise-server-releases.js):
- [ ] Prepend the new release number to the `supported` array.
- [ ] Increment the `next` variable above the `supported` array (e.g., new release number + `.1`).
- [ ] Increment the `nextNext` variable above the `supported` array (e.g., new release number + `.2`).
- [ ] Update the GHES dates file:
- [ ] Make sure you have a `.env` file at the root directory of your local checkout, and that it contains a PAT in the format of `GITHUB_TOKEN=<token>` with `repo` scope. Ensure the PAT is SSO-enabled for the `github` org.
- [ ] Run the script to update the dates file:
```
script/update-enterprise-dates.js
```
- [ ] Create REST files based on previous version. Copy the latest GHES release data to a new directory for new release. For example, if the current release is 3.8 and the new release is 3.9:
```
cp -rf src/rest/data/ghes-3.8 src/rest/data/ghes-3.9
```
- [ ] Create GraphQL files based on previous version. Copy the latest GHES release data to a new directory for new release. For example, if the current release is 3.8 and the new release is 3.9:
```
cp -rf src/graphql/data/ghes-3.8 src/graphql/data/ghes-3.9
cp -rf data/graphql/ghes-3.8 data/graphql/ghes-3.9
```
- [ ] Create webhook files based on previous version. Copy the latest GHES release data to a new directory for new release. For example, if the current release is 3.8 and the new release is 3.9:
```
cp -rf src/webhooks/data/ghes-3.8 src/webhooks/data/ghes-3.9
```
- [ ] Create GitHub App files based on previous version. Copy the latest GHES release data to a new directory for new release. For example, if the current release is 3.8 and the new release is 3.9:
```
cp -rf src/github-apps/data/ghes-3.8 src/github-apps/data/ghes-3.9
```
- [ ] Create a placeholder release notes file called `data/release-notes/<PRODUCT>/<RELEASE NUMBER>/PLACEHOLDER.yml`. For example `data/release-notes/enterprise-server/3-1/PLACEHOLDER.yml`. Add the following placeholder content to the file:
**Note:** All of the content in this file will be updated when the release notes are created in the megabranch including the filename `PLACEHOLDER.yml`. You can update the date or leave it as-is and wait to update it when the release notes are finalized.
<details><summary>Click to view placeholder...</summary>
```yaml
date: '2099-12-31'
release_candidate: true
deprecated: false
intro: |
{% note %}
**Note:** If {% data variables.location.product_location %} is running a release candidate build, you can’t upgrade with a hotpatch. We recommend that you only run release candidates in a test environment.
{% endnote %}
For upgrade instructions, see "[Upgrading {% data variables.product.prodname_ghe_server %}](/admin/enterprise-management/updating-the-virtual-machine-and-physical-resources/upgrading-github-enterprise-server)."
sections:
# Remove section heading if the section contains no notes.
features:
# Remove a sub-section heading if the heading contains no notes. If sections
# that regularly recur are missing, add placeholders to this template.
- heading: Instance administration
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Instance services
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Identity and access management
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Authentication
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Migrations
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Policies
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Audit logs
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: GitHub Connect
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: GitHub Advanced Security
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Dependabot
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Code security
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: GitHub Actions
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: GitHub Packages
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: GitHub Pages
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Community experience
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Organizations
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Repositories
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Issues
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Projects
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: GitHub Discussions
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Commits
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Pull requests
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Releases
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Gist
notes:
# LINK TO RELEASES ISSUE
- |
...
- heading: Markdown
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Accessibility
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: GitHub Mobile
notes:
# LINK TO RELEASE ISSUE
- |
...
- heading: Integrations and extensions
notes:
# LINK TO RELEASE ISSUE
- |
...
changes:
# LINK TO RELEASE ISSUE
- |
...
known_issues:
# INCLUDE NOTES FOR RELEASE FROM "GHES Release Note Tracking" PROJECT'S "Known Issues" TAB
- |
...
deprecations:
# LINK TO RELEASE ISSUE
- |
...
```
</details>
- [ ] If this is a release candidate release, add a Release Candidate banner:
```
script/enterprise-server-releases/release-banner.js --action create --version <PLAN@RELEASE>
script/copy-fixture-data.js // This updates the fixtures to match the updated data/variables/release_candidate.yml file
```
- [ ] Create a PR with the above changes. This PR is used to track all docs changes and smoke tests associated with the release. For example https://github.com/github/docs-internal/pull/22286.
### When the `docs-internal` release branch is open
- [ ] Add a label to the PR in this format:
```
sync-english-index-for-<PLAN@RELEASE>
```
☝️ This will run a workflow **on every push to the PR** that will sync **only** the English index for the new version. This will make the GHES content searchable on staging throughout content creation, and will ensure the search updates go live at the same time the content is published. See [`contributing/search.md`](https://github.com/github/docs-internal/blob/main/contributing/search.md) for details.
- [ ] Get the megabranch green with passing tests as soon as possible. This typically involves fixing broken links and working with engineering to address other unexpected test failures.
- [ ] Create an issue for the Code scanning and GHAS focus team to update the [`codeql_cli_ghes_recommended_version`](https://github.com/github/docs-internal/blob/main/data/variables/product.yml#L74) product variable to add the correct CodeQL CLI version for the upcoming GHES release.
- [ ] In `github/github`, use a Codespace to create a pull request that adds a new GHES release. Follow these steps (some of these steps may have already been done):
- [ ] Copy the previous release's configuration file to a new configuration file for this release `cp app/api/description/config/releases/ghes-<LATEST RELEASE NUMBER>.yaml app/api/description/config/releases/ghes-<NEXT RELEASE NUMBER>.yaml`.
- [ ] Update all references to the old GHES release number in that file to use the new GHES release number. There are about 4 occurrences at the time of this writing: `variables.externalDocsUrl`, `variables.ghesVersion`, and two keys under `patch` for the paths `/info/x-github-release` and `/externalDocs`.
- [ ] Update `published` in that file to `false`. **Note:** This is important to ensure that changes for the next version of the OpenAPI schema changes are not made public until the new version is released.
- [ ] Run `./bin/openapi generate-root-files` to generate the `app/api/description/ghes-<LATEST RELEASE NUMBER>.yaml` file and merge the changes.
- [ ] Create a PR with the two file changes `app/api/description/ghes-<NEW RELEASE NUMBER>.yaml` and `app/api/description/config/releases/ghes-<NEW RELEASE NUMBER>.yaml`
- [ ] Create a second PR based on the PR created ☝️ that toggles `published` to `true` in the `app/api/description/config/releases/ghes-<NEXT RELEASE NUMBER>.yaml` file. When this PR merges it will publish the new release to the `github/rest-api-description` repo and will trigger a pull request in the `github/docs-internal` repo with the schemas for the next GHES release. There is a step in this list to merge that PR in the "Before shipping the release branch" section.
- [ ] At least once a day until release, merge `main` into the megabranch and resolve any conflicts or failing tests.
### Troubleshooting
#### `Node.js tests / test content` failures
If the `Node.js tests / test content` check fails with the following message, the `lib/enterprise-dates.json` file is not up-to-date:
> FAIL tests/content/search.js ● search › has remote indexNames in every language for every supported GHE version
This file should be automatically updated, but you can also run `script/update-enterprise-dates.js` to update it. **Note:** If the test is still failing after running this script, look at the dates for this release. If the date is still inaccurate, it may be an issue with the source at https://github.com/github/enterprise-releases/blob/master/docs/supported-versions.md#release-lifecycle-dates. If that is the case, manually update the dates in the `lib/enterprise-dates.json` file.
### Before shipping the release branch
- [ ] 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.
- [ ] 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 the decorated JSON files for the new GHES release. If everything looks good, merge the "Update OpenAPI Description" PR into the GHES release megabranch. **Note:** Don't attempt to resolve conflicts for changes to the `src/rest/data` files. Instead delete the existing OpenAPI files for the release version from the megabranch (that is, revert the changes to the `src/rest/data` decorated JSON files, e.g., from the megabranch do a `git checkout origin/main src/rest/data/*`), 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
- [ ] Sync the search indices for the new release:
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 `ghes-<RELEASE>-megabranch` 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.
- [ ] 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. 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, 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 [`.github/ISSUE_TEMPLATE/release-tracking.yml`](https://github.com/github/docs-content/blob/main/.github/ISSUE_TEMPLATE/release-tracking.yml). When the PR is approved, merge it in.