Merge branch 'main' into find-page-in-version-redux

Author: sarahs

.github/actions-scripts/enterprise-algolia-label.js

@@ -0,0 +1,36 @@
+#!/usr/bin/env node
+
+const fs = require('fs')
+const core = require('@actions/core')
+const eventPayload = JSON.parse(fs.readFileSync(process.env.GITHUB_EVENT_PATH, 'utf8'))
+
+// This workflow-run script does the following:
+// 1. Gets an array of labels on a PR.
+// 2. Finds one with the relevant Algolia text; if none found, exits early.
+// 3. Gets the version substring from the label string.
+
+const labelText = 'sync-english-index-for-'
+const labelsArray = eventPayload.pull_request.labels
+
+// Exit early if no labels are on this PR
+if (!(labelsArray && labelsArray.length)) {
+  process.exit(0)
+}
+
+// Find the relevant label
+const algoliaLabel = labelsArray
+  .map(label => label.name)
+  .find(label => label.startsWith(labelText))
+
+// Exit early if no relevant label is found
+if (!algoliaLabel) {
+  process.exit(0)
+}
+
+// Given: sync-english-index-for-enterprise-server@3.0
+// Returns: enterprise-server@3.0
+const versionToSync = algoliaLabel.split(labelText)[1]
+
+// Store the version so we can access it later in the workflow
+core.setOutput('versionToSync', versionToSync)
+process.exit(0)

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

@@ -3,6 +3,8 @@ name: Algolia Sync Single English Index
 on:
   pull_request:
     types:
+      - labeled
+      - unlabeled
       - opened
       - reopened
       - synchronize
@@ -13,7 +15,7 @@ on:
 jobs:
   updateIndices:
     name: Update English index for single version based on a label's version
-    if: github.repository == 'github/docs-internal' && startsWith(github.event.label.name, 'sync-english-index-for-')
+    if: github.repository == 'github/docs-internal'
     runs-on: ubuntu-latest
     steps:
       - name: checkout
@@ -30,13 +32,13 @@ jobs:
             ${{ runner.os }}-node-
       - name: npm ci
         run: npm ci
-      - name: Get version from label
+      - name: Get version from Algolia label if present; only continue if the label is found.
         id: getVersion
-        run: |
-          echo "::set-output name=version::$(github.event.label.name.split('sync-english-index-for-')[1])"
-      - name: Sync English index for single version
+        run: $GITHUB_WORKSPACE/.github/actions-scripts/enterprise-algolia-label.js
+      - if: ${{ steps.getVersion.outputs.versionToSync }}
+        name: Sync English index for single version
         env:
-          VERSION: ${{ steps.getVersion.outputs.version }}
+          VERSION: ${{ steps.getVersion.outputs.versionToSync }}
           LANGUAGE: 'en'
           ALGOLIA_APPLICATION_ID: ${{ secrets.ALGOLIA_APPLICATION_ID }}
           ALGOLIA_API_KEY: ${{ secrets.ALGOLIA_API_KEY }}

content/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions.md

@@ -164,6 +164,12 @@ git:
 </tr>
 </table>
 
+#### Using environment variables in a matrix
+
+Travis CI and {% data variables.product.prodname_actions %} can both add custom environment variables to a test matrix, which allows you to refer to the variable in a later step.
+
+In {% data variables.product.prodname_actions %}, you can use the `include` key to add custom environment variables to a matrix. {% data reusables.github-actions.matrix-variable-example %}
+
 ### Key features in {% data variables.product.prodname_actions %}
 
 When migrating from Travis CI, consider the following key features in {% data variables.product.prodname_actions %}:

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

@@ -878,34 +878,9 @@ strategy:
 
 ##### Using environment variables in a matrix
 
-You can add custom environment variables for each test combination by using `include` with `env`. You can then refer to the custom environment variables in a later step.
+You can add custom environment variables for each test combination by using the `include` key. You can then refer to the custom environment variables in a later step.
 
-In this example, the matrix entries for `node-version` are each configured to use different values for the `site` and `datacenter` environment variables. The `Echo site details` step then uses {% raw %}`env: ${{ matrix.env }}`{% endraw %} to refer to the custom variables:
-
-{% raw %}
-```yaml
-name: Node.js CI
-on: [push]
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    strategy:
-      matrix:
-       include:
-         - node-version: 10.x
-           site: "prod"
-           datacenter: "site-a"
-         - node-version: 12.x
-           site: "dev"
-           datacenter: "site-b"
-    steps:
-    - name: Echo site details
-      env:
-        SITE: ${{ matrix.site }}
-        DATACENTER: ${{ matrix.datacenter }}
-      run: echo $SITE $DATACENTER
-```
-{% endraw %}
+{% data reusables.github-actions.matrix-variable-example %}
 
 ### **`jobs.<job_id>.strategy.fail-fast`**
 

content/admin/enterprise-management/configuring-high-availability-replication-for-a-cluster.md

@@ -57,32 +57,36 @@ Before you define a secondary datacenter for your passive nodes, ensure that you
       mysql-master = <em>HOSTNAME</em>
       redis-master = <em>HOSTNAME</em>
       <strong>primary-datacenter = default</strong>
-  ```
+    ```
 
     - Optionally, change the name of the primary datacenter to something more descriptive or accurate by editing the value of `primary-datacenter`.
 
 4. {% data reusables.enterprise_clustering.configuration-file-heading %} Under each node's heading, add a new key-value pair to assign the node to a datacenter. Use the same value as `primary-datacenter` from step 3 above. For example, if you want to use the default name (`default`), add the following key-value pair to the section for each node.
 
-      datacenter = default
+    ```
+    datacenter = default
+    ```
 
     When you're done, the section for each node in the cluster configuration file should look like the following example. {% data reusables.enterprise_clustering.key-value-pair-order-irrelevant %}
 
-  ```shell
-  [cluster "<em>HOSTNAME</em>"]
-    <strong>datacenter = default</strong>
-    hostname = <em>HOSTNAME</em>
-    ipv4 = <em>IP ADDRESS</em>
+    ```shell
+    [cluster "<em>HOSTNAME</em>"]
+      <strong>datacenter = default</strong>
+      hostname = <em>HOSTNAME</em>
+      ipv4 = <em>IP ADDRESS</em>
+      ...
     ...
-  ...
-  ```
+    ```
 
-  {% note %}
+    {% note %}
 
-  **Note**: If you changed the name of the primary datacenter in step 3, find the `consul-datacenter` key-value pair in the section for each node and change the value to the renamed primary datacenter. For example, if you named the primary datacenter `primary`, use the following key-value pair for each node.
+    **Note**: If you changed the name of the primary datacenter in step 3, find the `consul-datacenter` key-value pair in the section for each node and change the value to the renamed primary datacenter. For example, if you named the primary datacenter `primary`, use the following key-value pair for each node.
 
-      consul-datacenter = primary
+    ```
+    consul-datacenter = primary
+    ```
 
-  {% endnote %}
+    {% endnote %}
 
 {% data reusables.enterprise_clustering.apply-configuration %}
 
@@ -103,31 +107,37 @@ For an example configuration, see "[Example configuration](#example-configuratio
 
 1. For each node in your cluster, provision a matching virtual machine with identical specifications, running the same version of  {% data variables.product.prodname_ghe_server %}. Note the IPv4 address and hostname for each new cluster node. For more information, see "[Prerequisites](#prerequisites)."
 
-  {% note %}
+    {% note %}
 
-  **Note**: If you're reconfiguring high availability after a failover, you can use the old nodes from the primary datacenter instead.
+    **Note**: If you're reconfiguring high availability after a failover, you can use the old nodes from the primary datacenter instead.
 
-  {% endnote %}
+    {% endnote %}
 
 {% data reusables.enterprise_clustering.ssh-to-a-node %}
 
 3. Back up your existing cluster configuration.
 
-        cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup
+    ```
+    cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup
+    ```
 
 4. Create a copy of your existing cluster configuration file in a temporary location, like _/home/admin/cluster-passive.conf_. Delete unique key-value pairs for IP addresses (`ipv*`), UUIDs (`uuid`), and public keys for WireGuard (`wireguard-pubkey`).
 
-        grep -Ev "(?:|ipv|uuid|vpn|wireguard\-pubkey)" /data/user/common/cluster.conf > ~/cluster-passive.conf
+    ```
+    grep -Ev "(?:|ipv|uuid|vpn|wireguard\-pubkey)" /data/user/common/cluster.conf > ~/cluster-passive.conf
+    ```
 
 5. Remove the `[cluster]` section from the temporary cluster configuration file that you copied in the previous step.
 
-        git config -f ~/cluster-passive.conf --remove-section cluster
+    ```
+    git config -f ~/cluster-passive.conf --remove-section cluster
+    ```
 
 6. Decide on a name for the secondary datacenter where you provisioned your passive nodes, then update the temporary cluster configuration file with the new datacenter name. Replace `SECONDARY` with the name you choose.
 
     ```shell
-  sed -i 's/datacenter = default/datacenter = <em>SECONDARY</em>/g' ~/cluster-passive.conf
-  ```
+    sed -i 's/datacenter = default/datacenter = <em>SECONDARY</em>/g' ~/cluster-passive.conf
+    ```
 
 7. Decide on a pattern for the passive nodes' hostnames.
 
@@ -140,7 +150,7 @@ For an example configuration, see "[Example configuration](#example-configuratio
 8. Open the temporary cluster configuration file from step 3 in a text editor. For example, you can use Vim.
 
     ```shell
-        sudo vim ~/cluster-passive.conf
+    sudo vim ~/cluster-passive.conf
     ```
 
 9. In each section within the temporary cluster configuration file, update the node's configuration. {% data reusables.enterprise_clustering.configuration-file-heading %}
@@ -150,37 +160,37 @@ For an example configuration, see "[Example configuration](#example-configuratio
     - Add a new key-value pair, `replica = enabled`.
 
     ```shell
-  [cluster "<em>NEW PASSIVE NODE HOSTNAME</em>"]
-    ...
-    hostname = <em>NEW PASSIVE NODE HOSTNAME</em>
-    ipv4 = <em>NEW PASSIVE NODE IPV4 ADDRESS</em>
-    <strong>replica = enabled</strong>
+    [cluster "<em>NEW PASSIVE NODE HOSTNAME</em>"]
+      ...
+      hostname = <em>NEW PASSIVE NODE HOSTNAME</em>
+      ipv4 = <em>NEW PASSIVE NODE IPV4 ADDRESS</em>
+      <strong>replica = enabled</strong>
+      ...
     ...
-  ...
     ```
 
 10. Append the contents of the temporary cluster configuration file that you created in step 4 to the active configuration file.
 
     ```shell
-  cat ~/cluster-passive.conf >> /data/user/common/cluster.conf
-  ```
+    cat ~/cluster-passive.conf >> /data/user/common/cluster.conf
+    ```
 
 11. Designate the primary MySQL and Redis nodes in the secondary datacenter. Replace `REPLICA MYSQL PRIMARY HOSTNAME` and `REPLICA REDIS PRIMARY HOSTNAME` with the hostnames of the passives node that you provisioned to match your existing MySQL and Redis primaries.
 
     ```shell
-  git config -f /data/user/common/cluster.conf cluster.mysql-master-replica <em>REPLICA MYSQL PRIMARY HOSTNAME</em>
-  git config -f /data/user/common/cluster.conf cluster.redis-master-replica <em>REPLICA REDIS PRIMARY HOSTNAME</em>
-  ```
+    git config -f /data/user/common/cluster.conf cluster.mysql-master-replica <em>REPLICA MYSQL PRIMARY HOSTNAME</em>
+    git config -f /data/user/common/cluster.conf cluster.redis-master-replica <em>REPLICA REDIS PRIMARY HOSTNAME</em>
+    ```
 
 12. Enable MySQL to fail over automatically when you fail over to the passive replica nodes.
 
     ```shell
-  git config -f /data/user/common/cluster.conf cluster.mysql-auto-failover true
+    git config -f /data/user/common/cluster.conf cluster.mysql-auto-failover true
     ```
 
-  {% warning %}
+    {% warning %}
 
-  **Warning**: Review your cluster configuration file before proceeding.
+    **Warning**: Review your cluster configuration file before proceeding.
 
     - In the top-level `[cluster]` section, ensure that the values for `mysql-master-replica` and `redis-master-replica` are the correct hostnames for the passive nodes in the secondary datacenter that will serve as the MySQL and Redis primaries after a failover.
     - In each section for an active node named <code>[cluster "<em>ACTIVE NODE HOSTNAME</em>"]</code>, double-check the following key-value pairs.
@@ -194,9 +204,9 @@ For an example configuration, see "[Example configuration](#example-configuratio
       - `replica` should be configured as `enabled`.
     - Take the opportunity to remove sections for offline nodes that are no longer in use.
 
-  To review an example configuration, see "[Example configuration](#example-configuration)."
+    To review an example configuration, see "[Example configuration](#example-configuration)."
 
-  {% endwarning %}
+    {% endwarning %}
 
 13. Initialize the new cluster configuration. {% data reusables.enterprise.use-a-multiplexer %}
 
@@ -207,7 +217,7 @@ For an example configuration, see "[Example configuration](#example-configuratio
 14. After the initialization finishes, {% data variables.product.prodname_ghe_server %} displays the following message.
 
     ```shell
-        Finished cluster initialization
+    Finished cluster initialization
     ```
 
 {% data reusables.enterprise_clustering.apply-configuration %}
@@ -294,19 +304,27 @@ You can monitor the progress on any node in the cluster, using command-line tool
 
 - Monitor replication of databases:
 
-      /usr/local/share/enterprise/ghe-cluster-status-mysql
+  ```
+  /usr/local/share/enterprise/ghe-cluster-status-mysql
+  ```
 
 - Monitor replication of repository and Gist data:
 
-      ghe-spokes status
+  ```
+  ghe-spokes status
+  ```
 
 - Monitor replication of attachment and LFS data:
 
-      ghe-storage replication-status
+  ```
+  ghe-storage replication-status
+  ```
 
 - Monitor replication of Pages data:
 
-      ghe-dpages replication-status
+  ```
+  ghe-dpages replication-status
+  ```
 
 You can use `ghe-cluster-status` to review the overall health of your cluster. For more information, see  "[Command-line utilities](/enterprise/admin/configuration/command-line-utilities#ghe-cluster-status)."