Merge pull request #35992 from github/repo-sync

Repo sync

Author: docs-bot

content/actions/sharing-automations/creating-actions/creating-a-docker-container-action.md

@@ -179,8 +179,8 @@ git push --follow-tags
 
 Now you're ready to test your action out in a workflow.
 
-{% ifversion private-actions %}- When an action is in a private repository, you can control who can access it. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository).{% else %}- When an action is in a private repository, the action can only be used in workflows in the same repository.{% endif %}
-{% ifversion ghes or ghec %}{% ifversion internal-actions %}- When an action is in an internal repository, you can control who can access it. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository).{% else %}- When an action is in an internal repository, the action can only be used in workflows in the same repository.{% endif %}{% endif %}
+* When an action is in a private repository, you can control who can access it. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository).
+* {% ifversion ghes or ghec %}When an action is in an internal repository, you can control who can access it. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository).{% else %}When an action is in an internal repository, the action can only be used in workflows in the same repository.{% endif %}
 * Public actions can be used by workflows in any repository.
 
 {% data reusables.actions.enterprise-marketplace-actions %}

content/actions/sharing-automations/reusing-workflows.md

@@ -60,9 +60,8 @@ A reusable workflow can be used by another workflow if any of the following is t
   You cannot directly use reusable workflows defined on {% data variables.product.prodname_dotcom_the_website %}. Instead store a copy of the reusable workflow on {% data variables.location.product_location %}, and call the workflow from that path.
 
   {% elsif actions-workflow-policy %}, and your {% ifversion ghec %}enterprise{% else %}organization{% endif %} allows you to use public reusable workflows.{% endif %}{% ifversion ghes or ghec %}
-* The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. For more information, see {% ifversion internal-actions %}[AUTOTITLE](/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise){% else %}[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository){% endif %}.{% endif %}{% ifversion private-actions %}
+* The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. For more information, see {% ifversion internal-actions %}[AUTOTITLE](/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise){% else %}[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository){% endif %}.{% endif %}
 * The called workflow is stored in a private repository and the settings for that repository allow it to be accessed. For more information, see {% ifversion ghes or ghec %}[AUTOTITLE](/actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise).{% else %}[AUTOTITLE](/actions/creating-actions/sharing-actions-and-workflows-with-your-organization) and [AUTOTITLE](/actions/creating-actions/sharing-actions-and-workflows-from-your-private-repository).{% endif %}
-{% endif %}
 
 The following table shows the accessibility of reusable workflows to a caller workflow, depending on the visibility of the host repository.
 
@@ -103,7 +102,6 @@ Called workflows that are owned by the same user or organization{% ifversion ghe
 * Reusable workflows can't call other reusable workflows.
 * You can call a maximum of 20 unique reusable workflows from a single workflow file.
 {% endif %}
-{% ifversion private-actions %}{% else %}- Reusable workflows stored within a private repository can only be used by workflows within the same repository.{% endif %}
 * Any environment variables set in an `env` context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/learn-github-actions/contexts#env-context).
 * Similarly, environment variables set in the `env` context, defined in the called workflow, are not accessible in the `env` context of the caller workflow. Instead, you must use outputs of the reusable workflow. For more information, see [Using outputs from a reusable workflow](#using-outputs-from-a-reusable-workflow).
 * To reuse variables in multiple workflows, set them at the organization, repository, or environment levels and reference them using the `vars` context. For more information see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/learn-github-actions/contexts#vars-context).

content/actions/sharing-automations/sharing-actions-and-workflows-with-your-enterprise.md

@@ -12,20 +12,20 @@ redirect_from:
   - /actions/creating-actions/sharing-actions-and-workflows-with-your-enterprise
 ---
 
-## About {% data variables.product.prodname_actions %} access to internal {% ifversion private-actions %}and private {% endif %}repositories
+## About {% data variables.product.prodname_actions %} access to internal and private repositories
 
-If your organization is owned by an enterprise account, you can share actions and reusable workflows within your enterprise, without publishing them publicly, by allowing {% data variables.product.prodname_actions %} workflows to access an internal {% ifversion private-actions %}or private {% endif %}repository that contains the action or reusable workflow.
+If your organization is owned by an enterprise account, you can share actions and reusable workflows within your enterprise, without publishing them publicly, by allowing {% data variables.product.prodname_actions %} workflows to access an internal or private repository that contains the action or reusable workflow.
 
-Any actions or reusable workflows stored in the internal {% ifversion private-actions %}or private {% endif %}repository can be used in workflows defined in other internal or private repositories owned by the same organization, or by any organization owned by the enterprise. Actions and reusable workflows stored in internal repositories cannot be used in public repositories {% ifversion private-actions %}and actions and reusable workflows stored in private repositories cannot be used in public or internal repositories{% endif %}.
+Any actions or reusable workflows stored in the internal or private repository can be used in workflows defined in other internal or private repositories owned by the same organization, or by any organization owned by the enterprise. Actions and reusable workflows stored in internal repositories cannot be used in public repositories and actions and reusable workflows stored in private repositories cannot be used in public or internal repositories.
 
 > [!WARNING]
 > * {% data reusables.actions.outside-collaborators-actions %}
 > * {% data reusables.actions.scoped-token-note %}
 
 ## Sharing actions and workflows with your enterprise
 
-1. Store the action or reusable workflow in an internal {% ifversion private-actions %}or private {% endif %}repository. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories).
-1. Configure the repository to allow access to workflows in other internal {% ifversion private-actions %}or private {% endif %}repositories. For more information, see {% ifversion private-actions %}[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository) and {% endif %}[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository).
+1. Store the action or reusable workflow in an internal or private repository. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories).
+1. Configure the repository to allow access to workflows in other internal or private repositories. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository) and [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository).
 
 ## Further reading
 

content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise.md

@@ -123,7 +123,7 @@ People with admin permissions can set a more granular forking policy. For more i
 
 {% data reusables.enterprise-managed.repo-collaborators-note %}
 
-Across all organizations owned by your enterprise, you can allow members to invite{% ifversion ghec %} outside{% endif %} collaborators to repositories, restrict {% ifversion ghec %}outside collaborator {% endif %}invitations to organization owners, {% ifversion prevent-org-admin-add-outside-collaborator %}restrict {% ifversion ghec %}outside collaborator {% endif %}invitations to enterprise owners, {% endif %}or allow organization owners to administer the setting on the organization level.
+Across all organizations owned by your enterprise, you can allow members to invite{% ifversion ghec %} outside{% endif %} collaborators to repositories, restrict {% ifversion ghec %}outside collaborator {% endif %}invitations to organization owners, restrict {% ifversion ghec %}outside collaborator {% endif %}invitations to enterprise owners, or allow organization owners to administer the setting on the organization level.
 
 {% data reusables.enterprise-accounts.access-enterprise %}
 {% data reusables.enterprise-accounts.policies-tab %}
@@ -209,7 +209,7 @@ By default, when you enforce repository upload limits, people cannot add or upda
 
    ![Screenshot of the "Repository upload limit" policy section. The "Enforce on all repositories" checkbox is highlighted with an orange outline.](/assets/images/enterprise/site-admin-settings/all-repo-upload-limit-option.png)
 
-{% ifversion profile-name-enterprise-setting %}
+{% ifversion ghes %}
 
 ## Enforcing a policy for the display of member names in your repositories
 

content/copilot/building-copilot-extensions/about-building-copilot-extensions.md

@@ -55,16 +55,18 @@ For more information about skillsets, see [AUTOTITLE](/copilot/building-copilot-
 
 {% data reusables.copilot.copilot-extensions.context-passing-public-preview-note %}
 
-You can allow your {% data variables.product.prodname_copilot_extension_short %} to receive context from the editor, such as the currently opened file, by enabling the **Read-only** access level for the "{% data variables.product.prodname_copilot_short %} Editor Context" permission in your {% data variables.product.prodname_github_app %} settings. See [AUTOTITLE](/copilot/building-copilot-extensions/creating-a-copilot-extension/creating-a-github-app-for-your-copilot-extension#creating-a-github-app).
+You can allow your {% data variables.product.prodname_copilot_extension_short %} to receive context from the editor, such as the currently opened file, by enabling the **Read-only** access level for the "{% data variables.product.prodname_copilot_short %} Editor Context" permission in your {% data variables.product.prodname_github_app %} settings. See step 10 of [Configuring your {% data variables.product.prodname_github_app %}](/copilot/building-copilot-extensions/creating-a-copilot-extension/configuring-your-github-app-for-your-copilot-extension#configuring-your-github-app).
 
-The {% data variables.product.prodname_copilot_extensibility_platform %} automatically handles messaging when implicit and explicit context is unavailable or unauthorized. To enable context passing, you are required to request permissions from users. When requesting permissions, follow these best practices:
+The {% data variables.product.prodname_copilot_extensibility_platform %} automatically handles messaging when implicit and explicit context is unavailable or unauthorized. To enable context passing, you are required to request permissions from users. To enable context passing, you are required to:
 
-* Clearly communicate what context you need and what you need it for.
-* Implement appropriate error handling for unavailable context that your own application logic and API calls.
-* In the event context is unavailable, provide value where possible without this data.
-* Request only the minimum required permissions for your extension.
+* Update your APIs to handle new reference types.
+* Request permissions from users. When requesting permissions, follow these best practices:
+  * Clearly communicate what context you need and what you need it for.
+  * Implement appropriate error handling for unavailable context that your own application logic and API calls.
+  * If context is unavailable, provide value where possible without this data.
+  * Request only the minimum required permissions for your extension.
 
-Context passing respects content exclusions, `.env` files, and files listed in the content exclusion settings.
+Context passing respects content exclusions, which refers to any files listed in your context exclusion settings, including files that begin with `.`.
 
 ### Resources for building {% data variables.product.prodname_copilot_extensions %}
 

content/copilot/using-github-copilot/using-extensions-to-integrate-external-tools-with-copilot-chat.md

@@ -46,7 +46,7 @@ You can interact with your custom-built or installed extension in a {% data vari
 
 {% data variables.product.prodname_copilot_extensions %} can access certain contextual information depending on where you're using them. This context passing happens automatically when you interact with an extension, but requires your explicit authorization through {% data variables.product.prodname_github_app %} permissions for use in any organization-owned repositories.
 
-Context passing helps extensions understand your current work environment to provide more relevant assistance, while maintaining security through permission controls. Context passing also respects content exclusions, `.env` files, and files listed in your content exclusion settings.
+Context passing helps extensions understand your current work environment to provide more relevant assistance, while maintaining security through permission controls. Context passing respects content exclusions, which refers to any files listed in your context exclusion settings, including files that begin with `.`.
 
 The following table shows the contexts that are passed to {% data variables.product.prodname_copilot_extensions %} based on the client or IDE you are using.
 
@@ -58,7 +58,7 @@ The following table shows the contexts that are passed to {% data variables.prod
 | {% data variables.product.prodname_vs %}      | Yes           | Yes                | Yes                 |         No           | Repository owner and branch                       |
 | {% data variables.product.prodname_dotcom_the_website %}         |    No         |        No          | Yes                 | Yes                  | Repository information and other {% data variables.product.github %} resources |
 | {% data variables.product.prodname_mobile %}      |        No     |     No            |     No              | Yes                  |             Not applicable                                        |
-| JetBrains IDEs     |         No    |       No           |           No        | Yes                  |                      Not applicable                             |
+| JetBrains IDEs     |         No    |       No           |           No        | No                  |                      Not applicable                             |
 
 {% endrowheaders %}
 

content/organizations/managing-organization-settings/managing-the-display-of-member-names-in-your-organization.md

@@ -21,7 +21,7 @@ Organization owners can manage the display of member names in an organization.
 
 Changes to the display of usernames within an organization will affect the display of other people's usernames, not your own. Each organization member chooses their own profile name in their settings. For more information, see [AUTOTITLE](/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#changing-your-profile-name).
 
-{% ifversion profile-name-enterprise-setting %}
+{% ifversion ghes %}
 You may not be able to configure this setting for your organization, if an enterprise owner has set a policy at the enterprise level. For more information, see [AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise#enforcing-a-policy-for-inviting-outside-collaborators-to-repositories).{% endif %}
 
 {% data reusables.profile.access_org %}

content/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/reinstating-a-former-outside-collaborators-access-to-your-organization.md

@@ -33,7 +33,7 @@ When you reinstate a former outside collaborator, you can restore:
 * Repository subscriptions (notification settings for watching, not watching, or ignoring a repository's activity)
 
 > [!TIP]
-> * Only organization owners can reinstate outside collaborators' access to an organization.{% ifversion prevent-org-admin-add-outside-collaborator %} Enterprise owners may further restrict the ability to reinstate outside collaborators' access to enterprise owners only.{% endif %} For more information, see [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization).
+> * Only organization owners can reinstate outside collaborators' access to an organization. Enterprise owners may further restrict the ability to reinstate outside collaborators' access to enterprise owners only. For more information, see [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization).
 > * The reinstating a member flow on {% data variables.location.product_location %} may use the term "member" to describe reinstating an outside collaborator but if you reinstate this person and keep their previous privileges, they will only have their previous [outside collaborator permissions](/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#outside-collaborators).{% ifversion fpt or ghec %}
 > * If your organization has a paid per-user subscription, an unused license must be available before you can invite a new member to join the organization or reinstate a former organization member. For more information, see [AUTOTITLE](/billing/managing-the-plan-for-your-github-account/about-per-user-pricing).{% endif %}