Merge branch 'main' into adding-information-about-rates

.github/workflows/enterprise-dates.yml

@@ -4,8 +4,8 @@ name: Enterprise date updater
 # src/ghes-releases/lib/enterprise-dates.json.
 # **Why we have it**: The src/ghes-releases/lib/enterprise-dates.json
 # file needs to be up-to-date for the
-# .github/workflows/open-enterprise-issue.yml workflow and the
-# tests/content/search.js test.
+# Used to display deprecation banner dates and as a reference
+# for all past server release numbers.
 # **Who does it impact**: Docs engineering, docs content.
 
 on:

.github/workflows/open-enterprise-issue.yml → .github/workflows/enterprise-release-issue.yml

@@ -23,29 +23,13 @@ jobs:
 
       - uses: ./.github/actions/node-npm-setup
 
-      - name: Check for existing release or deprecation issues
-        id: existingIssue
-        run: |
-          src/versions/scripts/check-for-enterprise-issues-by-label.js
-        env:
-          GITHUB_TOKEN: ${{ secrets.DOCS_BOT_PAT_WRITEORG_PROJECT }}
-
-      - name: Update enterprise dates
-        if: steps.existingIssue.outputs.deprecationIssue == 'false' || steps.existingIssue.outputs.releaseIssue == 'false'
-        run: |
-          src/ghes-releases/scripts/update-enterprise-dates.js
-        env:
-          GITHUB_TOKEN: ${{ secrets.DOCS_BOT_PAT_WRITEORG_PROJECT }}
-
       - name: Create an enterprise release issue
-        if: steps.existingIssue.outputs.releaseIssue == 'false'
         run: |
           src/versions/scripts/create-enterprise-issue.js release
         env:
           GITHUB_TOKEN: ${{ secrets.DOCS_BOT_PAT_WRITEORG_PROJECT }}
 
       - name: Create an enterprise deprecation issue
-        if: steps.existingIssue.outputs.deprecationIssue == 'false'
         run: |
           src/versions/scripts/create-enterprise-issue.js deprecation
         env:

content/actions/deployment/deploying-to-your-cloud-provider/deploying-to-azure/deploying-to-azure-kubernetes-service.md

@@ -103,7 +103,7 @@ jobs:
       id: bake
 
     - name: Deploys application
-    - uses: Azure/k8s-deploy@dd4bbd13a5abd2fc9ca8bdcb8aee152bb718fa78
+      uses: Azure/k8s-deploy@dd4bbd13a5abd2fc9ca8bdcb8aee152bb718fa78
       with:
         manifests: {% raw %}${{ steps.bake.outputs.manifestsBundle }}{% endraw %}
         images: |

content/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent.md

@@ -119,7 +119,7 @@ Before adding a new SSH key to the ssh-agent to manage your keys, you should hav
 
    - Open your `~/.ssh/config` file, then modify the file to contain the following lines. If your SSH key file has a different name or path than the example code, modify the filename or path to match your current setup.
 
-     ```text replacedomain copy
+     ```text copy
      Host {% ifversion ghes %}HOSTNAME{% else %}github.com{% endif %}
        AddKeysToAgent yes
        UseKeychain yes
@@ -134,7 +134,7 @@ Before adding a new SSH key to the ssh-agent to manage your keys, you should hav
 
      - If you see a `Bad configuration option: usekeychain` error, add an additional line to the configuration's' `Host *.{% ifversion ghes %}HOSTNAME{% else %}github.com{% endif %}` section.
 
-       ```text replacedomain copy
+       ```text copy
        Host {% ifversion ghes %}HOSTNAME{% else %}github.com{% endif %}
          IgnoreUnknown UseKeychain
        ```

content/authentication/connecting-to-github-with-ssh/testing-your-ssh-connection.md

@@ -24,14 +24,14 @@ You'll need to authenticate this action using your password, which is the SSH ke
 {% data reusables.command_line.open_the_multi_os_terminal %}
 1. Enter the following:
 
-   ```shell replacedomain copy
+   ```shell copy
    ssh -T git@{% data variables.product.product_url %}
    # Attempts to ssh to {% data variables.product.product_name %}
    ```
 
    You may see a warning like this:
 
-   ```shell replacedomain
+   ```shell
    > The authenticity of host '{% data variables.product.product_url %} (IP ADDRESS)' can't be established.
    > ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
    > Are you sure you want to continue connecting (yes/no)?

content/authentication/troubleshooting-ssh/error-permission-denied-publickey.md

@@ -24,13 +24,13 @@ If you have a _very good reason_ you must use `sudo`, then ensure you are using
 
 To make sure you are connecting to the right domain, you can enter the following command:
 
-```shell replacedomain copy
+```shell copy
 ssh -vT git@{% data variables.product.product_url %}
 ```
 
 You should see this output:
 
-```shell replacedomain
+```shell
 > OpenSSH_8.1p1, LibreSSL 2.7.3
 > debug1: Reading configuration data /Users/YOU/.ssh/config
 > debug1: Reading configuration data /etc/ssh/ssh_config
@@ -44,7 +44,7 @@ The connection should be made on port 22{% ifversion fpt or ghec %}, unless you'
 
 All connections, including those for remote URLs, must be made as the "git" user. If you try to connect with your {% data variables.product.product_name %} username, it will fail:
 
-```shell replacedomain
+```shell
 $ ssh -T GITHUB-USERNAME@{% data variables.product.product_url %}
 > Permission denied (publickey).
 ```
@@ -53,7 +53,7 @@ If your connection failed and you're using a remote URL with your {% data variab
 
 You should verify your connection by typing:
 
-```shell replacedomain copy
+```shell copy
 ssh -T git@{% data variables.product.product_url %}
 ```
 
@@ -124,7 +124,7 @@ The `ssh-add` command _should_ print out a long string of numbers and letters. I
 
 You can also check that the key is being used by trying to connect to `git@{% data variables.product.product_url %}`:
 
-```shell replacedomain copy
+```shell copy
 ssh -vT git@{% data variables.product.product_url %}
 ```
 

content/organizations/managing-peoples-access-to-your-organization-with-roles/managing-security-managers-in-your-organization.md

@@ -46,8 +46,6 @@ You can assign the security manager role to a maximum of 10 teams in your organi
 
 ## Removing the security manager role from a team in your organization
 
-{% data reusables.organizations.warning-remove-security-managers %}
-
 {% data reusables.profile.access_org %}
 {% data reusables.profile.org_settings %}
 {% data reusables.organizations.security-and-analysis %}

content/rest/orgs/security-managers.md

@@ -18,6 +18,4 @@ autogenerated: rest
 
 {% data reusables.organizations.about-security-managers %}
 
-{% data reusables.organizations.warning-remove-security-managers %}
-
 <!-- Content after this section is automatically generated -->

src/ghes-releases/README.md

@@ -1,11 +1,7 @@
-# GHES releases
+# GHES releases and deprecations
 
 New GHES releases are cut about every 3 months and around the same time, the oldest release is deprecated (unofficially supported). The release schedule is located here: src/ghes-releases/lib/enterprise-dates.json
 
-## How does it work
-
-The docs content team creates new releases and the docs engineering team deprecates releases. An issue reminding the teams about releases and deprecations are opened up automatically in the docs-content (for releases) and docs-engineering repos (for deprecations).
-
 ## About this directory
 
 - `src/ghes-releases/lib` - The release and deprecation issue templates used as a checklist.
@@ -18,3 +14,43 @@ Slack: `#docs-engineering`
 Repo: `github/docs-engineering`
 
 If you have a question about this feature, you can ask in the `#docs-engineering` Slack channel. If you notice a problem with this feature, you can open an issue in the `github/docs-engineering` repository.
+
+## GHES releases
+
+Every day a workflow runs to check whether it's time to create new release tracking issues. New release tracking issues get opened on the code freeze date for the new release.
+
+New release issues get opened in the `docs-content` repo and use the templates located in `src/ghes-releases/lib/release-templates`.
+
+### Adding or removing templates
+
+Templates can be added and removed by simply adding a new file to the `release-template` directory using the naming convention that already exists. For every template in that directory, a new issue will be created. The issues are linked together using the tasklist in the parent template `release-steps-0.md`. Each template file has a corresponding liquid variable for the issue url created from the template. The liquid variable format is `{{ release-steps-<TEMPLATE NUMBER>-url }}`. The liquid variables can be used in the templates to autopopulate issues and link issues together.
+
+## GHES deprecations
+
+Every day a workflow runs to check whether it's time to create new deprecation tracking issues. New deprecation tracking issues get opened 7 days before the deprecation date. There is only one template used to generate the deprecation tracking issue (`src/ghes-releases/lib/deprecation-steps.md`).
+
+## Template format
+
+Templates in `src/ghes-releases/lib/release-templates` are Markdown, YAML frontmatter, and Liquid. The Liquid variables available to those templates are _not_ the same as liquid variables used by the Docs team for content and data. See the [Template variables](#template-variables) for the available variables.
+
+## Template variables
+
+- `{{ release-number }}` - The GHES release number. For example, `3.13`.
+- `{{ release-target-date }}` - The target GHES release date. For example, `2021-09-01`.
+- `{{ release-prp }}` - The enterprise team's primary responsible person (PRP) for the release.
+- `{{release-feature-freeze-date }}` - The feature freeze date for the release. For example, `2021-08-01`.
+- `{{ release-code-freeze-date }}` - The code freeze date for the release. For example, `2021-08-15`.
+- `{{ release-rc-target-date }}` - The release candidate target date for the release. For example, `2021-08-30`.
+- `{{ release-steps-0-url }}` - The URL of the issue that was created with the `release-steps-0.md` template.
+- `{{ release-steps-1-url }}` - The URL of the issue that was created with the `release-steps-1.md` template.
+- `{{ release-steps-2-url }}` - The URL of the issue that was created with the `release-steps-2.md` template.
+- `{{ release-steps-3-url }}` - The URL of the issue that was created with the `release-steps-3.md` template.
+- `{{ release-steps-4-url }}` - The URL of the issue that was created with the `release-steps-4.md` template.
+- `{{ release-steps-5-url }}` - The URL of the issue that was created with the `release-steps-5.md` template.
+- `{{ release-rc-target-date-minus-1 }}` - The day before the release candidate target date. For example, `2021-08-29`.
+- `{{ release-rc-target-date-minus-2 }}` - Two days before the release candidate target date. For example, `2021-08-28`.
+- `{{ release-rc-target-date-minus-3 }}` - Three days before the release candidate target date. For example, `2021-08-27`.
+- `{{ release-rc-target-date-minus-4 }}` - Four days before the release candidate target date. For example, `2021-08-26`.
+- `{{ release-rc-target-date-minus-5 }}` - Five days before the release candidate target date. For example, `2021-08-25`.
+- `{{ release-rc-target-date-minus-6 }}` - Six days before the release candidate target date. For example, `2021-08-24`.
+- `{{ release-rc-target-date-minus-7 }}` - Seven days before the release candidate target date. For example, `2021-08-23`.

src/ghes-releases/lib/deprecation-steps.md

@@ -1,3 +1,11 @@
+---
+title: Enterprise Server {{ release-number }} deprecation steps`
+labels:
+  - enterprise deprecation
+  - priority-1
+  - time sensitive
+---
+
 # Deprecation steps for GHES releases
 
 The day after a GHES version's [deprecation date](https://github.com/github/docs-internal/tree/main/src/ghes-releases/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.
@@ -13,32 +21,31 @@ Additionally, you can download:
 
 - [Azure Storage Explorer](https://aka.ms/portalfx/downloadstorageexplorer)
 
-## Step 0: Remove deprecated version numbers from docs-content issue forms
+## Step 0: Before beginning the deprecation, ensure the date of the deprecation is correctly defined
 
 - [ ] Completed step 0 ✅
 
-**Note**: This step can be performed independently of all other steps, and can be done several days before or along with the other steps.
+1. Check that the deprecation date is correct by looking up the version you are deprecating in the [release date list](https://github.com/github/enterprise-releases/blob/master/releases.json) and finding the corresponding `prp` owner. Send them a slack message to confirm that the date is correct. If the date is being pushed out, you can ask the `prp` to update the date in the release date list. If the release date list does not get updated (it doesn't always) we have to prepare that our version of that file (`src/ghes-releases/lib/enterprise-dates.json`) will also be inaccurate.
 
-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).
+   If there is no `prp` defined, reach out to our content friends for help in the #docs-content-enterprise Slack channel.
 
-When the PR is approved, merge it in.
+1. If this release is being pushed out, update the target date of this issue and you can wait to proceed with any futher steps.
 
-## Step 1: Before beginning the deprecation, ensure the date of the deprecation is correctly defined
+## Step 1: Remove deprecated version numbers from docs-content issue forms
 
 - [ ] Completed step 1 ✅
 
-The dates we use for Enterprise releases and deprecations are stored in [releases](https://github.com/github/enterprise-releases/blob/master/releases.json). However, that file isn't always up-to-date when deprecations get pushed out. This date is added to `src/ghes-releases/lib/enterprise-dates.json`, stored in this repo.
-
-1. Check that the deprecation date is correct by looking up the version you are deprecating in the [release date list](https://github.com/github/enterprise-releases/blob/master/releases.json) and finding the corresponding `prp` owner. Send them a slack message to confirm that the date is correct.
+**Note**: This step can be performed independently of all other steps, and can be done several days before or along with the other steps.
 
-   If there is no `prp` defined, reach out to our content friends for help in the #docs-content-enterprise Slack channel.
+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).
 
-2. If the actual deprecation date differs from what we have documented in `src/ghes-releases/lib/enterprise-dates.json`, update the date in that file. If the date is correct, there is nothing to do. The date in `src/ghes-releases/lib/enterprise-dates.json` will be the date used in the deprecation banner of the scraped content.
+When the PR is approved, merge it in.
 
 ## Step 2: Dry run: Scrape the docs and archive the files
 
 - [ ] Completed step 2 ✅
 
+1. If the release date documented in the [release date list](https://github.com/github/enterprise-releases/blob/master/releases.json) is incorrect or differs from what we have documented in `src/ghes-releases/lib/enterprise-dates.json`, update the date in `src/ghes-releases/lib/enterprise-dates.json` to the correct deprecation date before proceeding with the deprecation. A banner is displayed on each page with a version that will be deprecated soon. The banner uses the dates defined in `src/ghes-releases/lib/enterprise-dates.json`.
 1. Ensure you have local clones of the [translation repositories](#configuring-the-translation-repositories).
 1. Update all translation directories to the latest `main` branch.
 1. You can do this on the main branch or check out a new temporary branch.