Merge branch 'main' into issue-42851

Author: Sharra-writes

assets/images/help/billing/cost-center-example-2.png

@@ -50,7 +50,7 @@ To use a specific action version, users can configure their {% data variables.pr
 
 ### Using tags for release management
 
-{% ifversion fpt or ghec %}
+{% ifversion immutable-releases %}
 > [!NOTE] If you have enabled immutable releases to help prevent supply chain attacks and accidental changes to your releases, instead see [AUTOTITLE](/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases).
 {% endif %}
 

content/actions/how-tos/create-and-publish-actions/manage-custom-actions.md

@@ -55,7 +55,7 @@ To support the developer process in the next section, add two {% data variables.
 1. Add a workflow that triggers when a commit is pushed to a feature branch or to `main` or when a pull request is created. Configure the workflow to run your unit and integration tests. For an example, see [this workflow](https://github.com/actions/javascript-action/blob/main/.github/workflows/ci.yml).
 1. Add a workflow that triggers when a release is published or edited. Configure the workflow to ensure semantic tags are in place. You can use an action like [JasonEtco/build-and-tag-action](https://github.com/JasonEtco/build-and-tag-action) to compile and bundle the JavaScript and metadata file and force push semantic major, minor, and patch tags. For more information about semantic tags, see [About semantic versioning](https://docs.npmjs.com/about-semantic-versioning).
 
-    {% ifversion fpt or ghec %}
+    {% ifversion immutable-releases %}
     > [!NOTE]
     > If you enable immutable releases for your repository, you cannot use this action to force push tags tied to releases on {% data variables.product.github %}. To learn how to manage your releases with immutable releases, see [AUTOTITLE](/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases).
     {% endif %}

content/actions/how-tos/create-and-publish-actions/release-and-maintain-actions.md

@@ -3,8 +3,7 @@ title: Using immutable releases and tags to manage your action's releases
 shortTitle: Use immutable releases
 intro: 'Learn how you can use a combination of immutable releases on {% data variables.product.github %} and Git tags to manage your action''s releases.'
 versions:
-  fpt: '*'
-  ghec: '*'
+  feature: immutable-releases
 topics:
   - Actions
   - Code Security

content/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases.md

@@ -42,9 +42,6 @@ Use the labels in the table below to run your workflows on the corresponding mac
 
 {% data reusables.actions.larger-runners-table %}
 
-> [!NOTE]
-> For macOS {% data variables.actions.hosted_runner %}s, the `-latest` runner label uses the macOS 12 runner image. For macOS Xlarge, the `-latest` runner label uses the macOS 13 runner image
-
 {% endmac %}
 
 {% ifversion repository-actions-runners %}

content/actions/how-tos/manage-runners/larger-runners/use-larger-runners.md

@@ -38,7 +38,7 @@ When combined with OpenID Connect (OIDC), reusable workflows let you enforce con
 
 ## How the token works with reusable workflows
 
-During a workflow run, {% data variables.product.prodname_dotcom %}'s OIDC provider presents a OIDC token to the cloud provider which contains information about the job. If that job is part of a reusable workflow, the token will include the standard claims that contain information about the calling workflow, and will also include a custom claim called `job_workflow_ref` that contains information about the called workflow.
+During a workflow run, {% data variables.product.prodname_dotcom %}'s OIDC provider presents an OIDC token to the cloud provider which contains information about the job. If that job is part of a reusable workflow, the token will include the standard claims that contain information about the calling workflow, and will also include a custom claim called `job_workflow_ref` that contains information about the called workflow.
 
 For example, the following OIDC token is for a job that was part of a called workflow. The `workflow`, `ref`, and other attributes describe the caller workflow, while `job_workflow_ref` refers to the called workflow:
 

content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-with-reusable-workflows.md

@@ -122,7 +122,7 @@ In addition to runner environment variables, {% data variables.product.prodname_
 
 The `run` steps in a workflow, or in a referenced action, are processed by a runner. As a result, you can use runner environment variables here, using the appropriate syntax for the shell you are using on the runner - for example, `$NAME` for the bash shell on a Linux runner, or `$env:NAME` for PowerShell on a Windows runner. In most cases you can also use contexts, with the syntax {% raw %}`${{ CONTEXT.PROPERTY }}`{% endraw %}, to access the same value. The difference is that the context will be interpolated and replaced by a string before the job is sent to a runner.
 
-However, you cannot use runner environment variables in parts of a workflow that are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. Instead, you must use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You must therefore use a context in an `if` conditional statement to access the value of an variable.
+However, you cannot use runner environment variables in parts of a workflow that are processed by {% data variables.product.prodname_actions %} and are not sent to the runner. Instead, you must use contexts. For example, an `if` conditional, which determines whether a job or step is sent to the runner, is always processed by {% data variables.product.prodname_actions %}. You must therefore use a context in an `if` conditional statement to access the value of a variable.
 
 {% raw %}
 

content/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables.md

@@ -14,7 +14,7 @@ shortTitle: Releases
 
 ## Releases of {% data variables.product.prodname_ghe_server %}
 
-{% data variables.product.company_short %} supports the **four** most recent feature releases.
+{% data variables.product.company_short %} supports at least the **four** most recent feature releases.
 
 We provide documentation for both supported and unsupported versions of {% data variables.product.prodname_ghe_server %}. We do not maintain or update the documentation for unsupported versions.
 
@@ -58,6 +58,7 @@ If you run analysis in an external CI system, we recommend using the same versio
 
 | {% data variables.product.prodname_ghe_server %} version | Recommended {% data variables.product.prodname_codeql_cli %} version |
 | ------------------------------------------------- | ---------------------- |
+| 3.20 | 2.23.9 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.23.9/)) |
 | 3.19 | 2.22.4 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.22.4/)) |
 | 3.18 | 2.21.4 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.21.4/)) |
 | 3.17 | 2.20.7 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.20.7/)) |
@@ -79,6 +80,7 @@ For instances with {% data variables.product.prodname_actions %} enabled, self-h
 
 | {% data variables.product.prodname_ghe_server %} version | Minimum Runner version |
 | ------------------------------------------------- | ---------------------- |
+| 3.20 | 2.330.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.330.0)) |
 | 3.19 | 2.328.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.328.0)) |
 | 3.18 | 2.324.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.324.0)) |
 | 3.17 | 2.322.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.322.0)) |

content/admin/all-releases.md

@@ -12,7 +12,9 @@ topics:
   - Infrastructure
 ---
 
+{% ifversion ghes < 3.20 %}
 >[!NOTE] {% data variables.product.prodname_enterprise_backup_service %} is currently in {% data variables.release-phases.public_preview %} and subject to change. The service is available at no additional cost and will remain free.
+{% endif %}
 
 ## About the {% data variables.product.prodname_enterprise_backup_service %}
 
@@ -29,7 +31,9 @@ Compared to the legacy backup utilities, the {% data variables.product.prodname_
 * Doesn’t require a separate host for backup software.
 * Stores backups on a dedicated storage volume directly accessible by your instance.
 
+{% ifversion ghes < 3.20 %}
 >[!NOTE] {% data variables.product.prodname_enterprise_backup_service %} is currently only supported on standalone instances and high availability primary nodes. Cluster configurations and replica nodes are not yet supported.
+{% endif %}
 
 ## How does the backup service differ from a High Availability replica?
 
@@ -47,8 +51,7 @@ The backup service is a disaster recovery solution. It captures full, timestampe
 
 ## Further reading
 
-* [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/configuring-backups-on-your-instance)
-* [About {% data variables.product.prodname_enterprise_backup_utilities %}](https://github.com/github/backup-utils#readme)
-* [AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)
-* [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode)
-* [AUTOTITLE](/admin/github-actions/advanced-configuration-and-troubleshooting/backing-up-and-restoring-github-enterprise-server-with-github-actions-enabled)
+* [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/understanding-the-backup-service)
+* [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/configuring-the-backup-service)
+* [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/restoring-from-a-backup)
+* [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/restoring-with-github-actions-enabled)

content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/about-the-backup-service-for-github-enterprise-server.md

@@ -0,0 +1,30 @@
+---
+title: Backup from replica in high availability
+shortTitle: Backup from replica
+intro: 'Enable backup from a high availability replica node.'
+versions:
+  ghes: '> 3.19'
+type: how_to
+topics:
+  - Backups
+---
+
+## Configuring backups from a replica node
+
+For high availability, you can designate a replica node as your backup server. To minimize latency, {% data variables.product.github %} recommends picking a replica node in the same region or datacenter as your primary node.
+
+> [!IMPORTANT] 
+> Backups from cache replica nodes or active geo replica nodes are not supported.
+
+To configure your backup server, run the following commands, replacing `HOSTNAME` with the hostname of the node:
+
+```shell
+ghe-config cluster.HOSTNAME.backup-server true
+
+ghe-config-apply
+```
+
+You can now run `ghe-backup` directly on your replica node.
+
+> [!WARNING]
+> Due to the latency between primary and replica nodes, you may lose data when backing up from a replica node.