Merge branch 'main' into repo-sync

Author: Octomerger

assets/images/help/issues/burnup-example.png

@@ -8,7 +8,6 @@ import { Link } from 'components/Link'
 import { ProductTreeNode, useMainContext } from 'components/context/MainContext'
 import { AllProductsLink } from 'components/sidebar/AllProductsLink'
 import { EventType, sendEvent } from 'components/lib/events'
-
 import styles from './SidebarProduct.module.scss'
 
 export const SidebarProduct = () => {
@@ -154,7 +153,7 @@ const CollapsibleSection = (props: SectionProps) => {
     <details open={defaultOpen} onToggle={onToggle} className="details-reset">
       <summary className="outline-none">
         <div className="d-flex flex-justify-between">
-          <div className="pl-4 pr-1 py-2 f6 text-uppercase d-block flex-auto mr-3 color-fg-default no-underline text-bold">
+          <div className="pl-4 pr-1 py-2 f5 d-block flex-auto mr-3 color-fg-default no-underline text-bold">
             {title}
           </div>
           <span style={{ marginTop: 7 }} className="flex-shrink-0 pr-3">

assets/images/help/issues/iteration-insert-break.png

@@ -4,7 +4,8 @@ shortTitle: About deployments
 intro: 'Learn how deployments can run with {% data variables.product.prodname_actions %} workflows.'
 versions:
   fpt: '*'
-  ghae: issue-4856
+  ghes: '*'
+  ghae: '*'
   ghec: '*'
 children:
   - /about-continuous-deployment

assets/images/help/issues/iterations-example.png

@@ -4,7 +4,8 @@ shortTitle: Deploying Xcode applications
 intro: 'You can sign Xcode apps within your continuous integration (CI) workflow by installing an Apple code signing certificate on {% data variables.product.prodname_actions %} runners.'
 versions:
   fpt: '*'
-  ghae: issue-4856
+  ghes: '*'
+  ghae: '*'
   ghec: '*'
 children:
   - /installing-an-apple-certificate-on-macos-runners-for-xcode-development

components/sidebar/SidebarProduct.tsx

@@ -4,7 +4,8 @@ shortTitle: Managing your deployments
 intro: You can review the past activity of your deployments.
 versions:
   fpt: '*'
-  ghae: issue-4856
+  ghes: '*'
+  ghae: '*'
   ghec: '*'
 children:
   - /viewing-deployment-history

content/actions/deployment/about-deployments/index.md

@@ -4,7 +4,8 @@ shortTitle: Targeting different environments
 intro: You can configure environments with protection rules and secrets. A workflow job that references an environment must follow any protection rules for the environment before running or accessing the environment's secrets.
 versions:
   fpt: '*'
-  ghae: issue-4856
+  ghes: '*'
+  ghae: '*'
   ghec: '*'
 children:
   - /using-environments-for-deployment

content/actions/deployment/deploying-xcode-applications/index.md

@@ -51,7 +51,8 @@ For more information about installing and using self-hosted runners, see "[Addin
 - Can use cloud services or local machines that you already pay for.
 - Are customizable to your hardware, operating system, software, and security requirements.
 - Don't need to have a clean instance for every job execution.
-- Are free to use with {% data variables.product.prodname_actions %}, but you are responsible for the cost of maintaining your runner machines.
+- Are free to use with {% data variables.product.prodname_actions %}, but you are responsible for the cost of maintaining your runner machines.{% ifversion ghec or ghes or ghae %}
+- Can be organized into groups to restrict access to specific {% if restrict-groups-to-workflows %}workflows, {% endif %}organizations and repositories. For more information, see "[Managing access to self-hosted runners using groups](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)."{% endif %}
 
 ## Requirements for self-hosted runner machines
 

content/actions/deployment/managing-your-deployments/index.md

@@ -9,11 +9,12 @@ versions:
   ghae: '*'
   ghec: '*'
 type: tutorial
-shortTitle: Manage runner groups
+shortTitle: Manage access to runners
 ---
 
 {% data reusables.actions.enterprise-beta %}
 {% data reusables.actions.enterprise-github-hosted-runners %}
+{% data reusables.actions.restrict-runner-workflow-beta %}
 
 ## About self-hosted runner groups
 
@@ -30,9 +31,9 @@ If you use {% data variables.product.prodname_ghe_cloud %}, you can create addit
 {% endif %}
 
 {% ifversion ghec or ghes or ghae %}
-Self-hosted runner groups are used to control access to self-hosted runners at the organization and enterprise level. Enterprise admins can configure access policies that control which organizations in an enterprise have access to the runner group. Organization admins can configure access policies that control which repositories in an organization have access to the runner group.
+Self-hosted runner groups are used to control access to self-hosted runners at the organization and enterprise level. Enterprise owners can configure access policies that control which organizations {% if restrict-groups-to-workflows %}and workflows {% endif %}in an enterprise have access to the runner group. Organization owners can configure access policies that control which repositories{% if restrict-groups-to-workflows %} and workflows{% endif %} in an organization have access to the runner group.
 
-When an enterprise admin grants an organization access to a runner group, organization admins can see the runner group listed in the organization's self-hosted runner settings. The organizations admins can then assign additional granular repository access policies to the enterprise runner group.
+When an enterprise owner grants an organization access to a runner group, organization owners can see the runner group listed in the organization's self-hosted runner settings. The organization owners can then assign additional granular repository{% if restrict-groups-to-workflows %} and workflow{% endif %} access policies to the enterprise runner group.
 
 When new runners are created, they are automatically assigned to the default group. Runners can only be in one group at a time. You can move runners from the default group to another group. For more information, see "[Moving a self-hosted runner to a group](#moving-a-self-hosted-runner-to-a-group)."
 
@@ -42,13 +43,14 @@ All organizations have a single default self-hosted runner group. Organizations
 
 Self-hosted runners are automatically assigned to the default group when created, and can only be members of one group at a time. You can move a runner from the default group to any group you create.
 
-When creating a group, you must choose a policy that defines which repositories have access to the runner group.
+When creating a group, you must choose a policy that defines which repositories{% if restrict-groups-to-workflows %} and workflows{% endif %} have access to the runner group.
 
 {% ifversion ghec or ghes > 3.3 or ghae-issue-5091 %}
 {% data reusables.organizations.navigate-to-org %}
 {% data reusables.organizations.org_settings %}
 {% data reusables.actions.settings-sidebar-actions-runner-groups %}
 1. In the "Runner groups" section, click **New runner group**.
+1. Enter a name for your runner group.
  {% data reusables.actions.runner-group-assign-policy-repo %}
 
    {% warning %}
@@ -58,6 +60,7 @@ When creating a group, you must choose a policy that defines which repositories
    For more information, see "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories)."
 
    {% endwarning %}
+{% data reusables.actions.runner-group-assign-policy-workflow %}{%- if restrict-groups-to-workflows %} Organization-owned runner groups cannot access workflows from a different organization in the enterprise; instead, you must create an enterprise-owned runner group.{% endif %}
 {% data reusables.actions.self-hosted-runner-create-group %}
 {% elsif ghae or ghes < 3.4 %}
 {% data reusables.organizations.navigate-to-org %}
@@ -88,7 +91,7 @@ When creating a group, you must choose a policy that defines which repositories
 
 ## Creating a self-hosted runner group for an enterprise
 
-Enterprises can add their self-hosted runners to groups for access management. Enterprises can create groups of self-hosted runners that are accessible to specific organizations in the enterprise account. Organization admins can then assign additional granular repository access policies to the enterprise runner groups. For information about how to create a self-hosted runner group with the REST API, see the enterprise endpoints in the [{% data variables.product.prodname_actions %} REST API](/rest/reference/actions#self-hosted-runner-groups).
+Enterprises can add their self-hosted runners to groups for access management. Enterprises can create groups of self-hosted runners that are accessible to specific organizations in the enterprise account{% if restrict-groups-to-workflows %} or to specific workflows{% endif %}. Organization owners can then assign additional granular repository{% if restrict-groups-to-workflows %} or workflow{% endif %} access policies to the enterprise runner groups. For information about how to create a self-hosted runner group with the REST API, see the enterprise endpoints in the [{% data variables.product.prodname_actions %} REST API](/rest/reference/actions#self-hosted-runner-groups).
 
 Self-hosted runners are automatically assigned to the default group when created, and can only be members of one group at a time. You can assign the runner to a specific group during the registration process, or you can later move the runner from the default group to a custom group.
 
@@ -115,17 +118,21 @@ When creating a group, you must choose a policy that defines which organizations
 
    ![Add runner group options](/assets/images/help/settings/actions-enterprise-account-add-runner-group-options-ae.png)
    {%- endif %}
+{% data reusables.actions.runner-group-assign-policy-workflow %}
 1. Click **Save group** to create the group and apply the policy.
 
 {% endif %}
 
 ## Changing the access policy of a self-hosted runner group
 
-You can update the access policy of a runner group, or rename a runner group.
+For runner groups in an enterprise, you can change what organizations in the enterprise can access a runner group{% if restrict-groups-to-workflows %} or restrict what workflows a runner group can run{% endif %}. For runner groups in an organization, you can change what repositories in the organization can access a runner group{% if restrict-groups-to-workflows %} or restrict what workflows a runner group can run{% endif %}.
+
+### Changing what organizations or repositories can access a runner group
+
 {% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-5091 %}
 {% data reusables.actions.self-hosted-runner-groups-navigate-to-repo-org-enterprise %}
 {% data reusables.actions.settings-sidebar-actions-runner-groups-selection %}
-1. Modify the access options, or change the runner group name.
+1. For runner groups in an enterprise, under **Organization access**, modify what organizations can access the runner group. For runner groups in an organization, under **Repository access**, modify what repositories can access the runner group.
 
    {%- ifversion fpt or ghec or ghes %}
    {% warning %}
@@ -142,6 +149,35 @@ You can update the access policy of a runner group, or rename a runner group.
 {% data reusables.actions.self-hosted-runner-configure-runner-group-access %}
 {% endif %}
 
+{% if restrict-groups-to-workflows %}
+### Changing what workflows can access a runner group
+You can configure a self-hosted runner group to run either selected workflows or all workflows. For example, you might use this setting to protect secrets that are stored on self-hosted runners or to standardize deployment workflows by restricting a runner group to run only a specific reusable workflow. This setting cannot be overridden if you are configuring an organization's runner group that was shared by an enterprise. 
+{% data reusables.actions.self-hosted-runner-groups-navigate-to-repo-org-enterprise %}
+{% data reusables.actions.settings-sidebar-actions-runner-groups-selection %}
+1. Under **Workflow access**, select the dropdown menu and click **Selected workflows**.
+1. Click {% octicon "gear" aria-label="the gear icon" %}.
+1. Enter a comma separated list of the workflows that can access the runner group. Use the full path, including the repository name and owner. Pin the workflow to a branch, tag, or full SHA. For example: `octo-org/octo-repo/.github/workflows/build.yml@v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@main`.
+
+   Only jobs directly defined within the selected workflows will have access to the runner group.
+   
+   Organization-owned runner groups cannot access workflows from a different organization in the enterprise; instead, you must create an enterprise-owned runner group.
+
+1. Click **Save**.
+
+{% endif %}
+
+## Changing the name of a runner group
+
+{% ifversion fpt or ghec or ghes > 3.3 or ghae-issue-5091 %}
+{% data reusables.actions.self-hosted-runner-groups-navigate-to-repo-org-enterprise %}
+{% data reusables.actions.settings-sidebar-actions-runner-groups-selection %}
+1. Change the runner group name.
+
+{% elsif ghae or ghes < 3.4 %}
+{% data reusables.actions.self-hosted-runner-configure-runner-group %}
+1. Change the runner group name.
+{% endif %}
+
 {% ifversion ghec or ghes or ghae %}
 ## Automatically adding a self-hosted runner to a group