Merge pull request github#34731 from github/repo-sync

Repo sync

content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md

@@ -51,7 +51,7 @@ You can use the self-hosted runner application's `config` script with the `--che
 In addition to `--check`, you must provide two arguments to the script:
 
 * `--url` with the URL to your {% data variables.product.company_short %} repository, organization, or enterprise. For example, `--url https://github.com/octo-org/octo-repo`.
-* `--pat` with the value of a {% data variables.product.pat_v1 %}, which must have the `workflow` scope{% ifversion pat-v2%}, or a {% data variables.product.pat_v2 %} with workflows read and write access {% endif %}. For example, `--pat ghp_abcd1234`. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)."
+* `--pat` with the value of a {% data variables.product.pat_v1 %}, which must have the `workflow` scope, or a {% data variables.product.pat_v2 %} with workflows read and write access. For example, `--pat ghp_abcd1234`. For more information, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)."
 
 For example:
 

content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md

@@ -297,7 +297,7 @@ This list describes the recommended approaches for accessing repository data wit
     * {% data variables.product.prodname_github_apps %} can be installed on select repositories, and even have granular permissions on the resources within them. You could create a {% data variables.product.prodname_github_app %} internal to your organization, install it on the repositories you need access to within your workflow, and authenticate as the installation within your workflow to access those repositories. For more information, see "[AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)."
 1. **{% data variables.product.pat_generic %}s**
     * You should never use a {% data variables.product.pat_v1 %}. These tokens grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your personal account. This indirectly grants broad access to all write-access users of the repository the workflow is in.
-    * If you do use a {% data variables.product.pat_generic %}, you should never use a {% data variables.product.pat_generic %} from your own account. If you later leave an organization, workflows using this token will immediately break, and debugging this issue can be challenging. Instead, you should use a {% ifversion pat-v2%}{% data variables.product.pat_v2 %}s{% else %}{% data variables.product.pat_generic %}s{% endif %} for a new account that belongs to your organization and that is only granted access to the specific repositories that are needed for the workflow. Note that this approach is not scalable and should be avoided in favor of alternatives, such as deploy keys.
+    * If you do use a {% data variables.product.pat_generic %}, you should never use a {% data variables.product.pat_generic %} from your own account. If you later leave an organization, workflows using this token will immediately break, and debugging this issue can be challenging. Instead, you should use a {% data variables.product.pat_v2 %}for a new account that belongs to your organization and that is only granted access to the specific repositories that are needed for the workflow. Note that this approach is not scalable and should be avoided in favor of alternatives, such as deploy keys.
 1. **SSH keys on a personal account**
     * Workflows should never use the SSH keys on a personal account. Similar to {% data variables.product.pat_v1_plural %}, they grant read/write permissions to all of your personal repositories as well as all the repositories you have access to through organization membership.  This indirectly grants broad access to all write-access users of the repository the workflow is in. If you're intending to use an SSH key because you only need to perform repository clones or pushes, and do not need to interact with public APIs, then you should use individual deploy keys instead.
 

content/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions.md

@@ -61,9 +61,9 @@ You can also manage secrets using the REST API. For more information, see "[AUTO
 
 When generating credentials, we recommend that you grant the minimum permissions possible. For example, instead of using personal credentials, use [deploy keys](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys) or a service account. Consider granting read-only permissions if that's all that is needed, and limit access as much as possible.
 
-When generating a {% data variables.product.pat_v1 %}, select the fewest scopes necessary.{% ifversion pat-v2 %} When generating a {% data variables.product.pat_v2 %}, select the minimum permissions and repository access required.{% endif %}
+When generating a {% data variables.product.pat_v1 %}, select the fewest scopes necessary. When generating a {% data variables.product.pat_v2 %}, select the minimum permissions and repository access required.
 
-Instead of using a {% data variables.product.pat_generic %}, consider using a {% data variables.product.prodname_github_app %}, which uses fine-grained permissions and short lived tokens{% ifversion pat-v2 %}, similar to a {% data variables.product.pat_v2 %}{% endif %}. Unlike a {% data variables.product.pat_generic %}, a {% data variables.product.prodname_github_app %} is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see "[AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)."
+Instead of using a {% data variables.product.pat_generic %}, consider using a {% data variables.product.prodname_github_app %}, which uses fine-grained permissions and short lived tokens, similar to a {% data variables.product.pat_v2 %}. Unlike a {% data variables.product.pat_generic %}, a {% data variables.product.prodname_github_app %} is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see "[AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)."
 
 {% note %}
 

content/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-scim-provisioning-for-users.md

@@ -27,6 +27,20 @@ topics:
 
 If you use a partner IdP, you can simplify the configuration of SCIM provisioning by using the partner IdP's application. If you don't use a partner IdP for provisioning, you can implement SCIM using calls to {% data variables.product.company_short %}'s REST API for SCIM{% ifversion ghec %}, which is in beta and subject to change{% endif %}. For more information, see {% ifversion ghec %}"[AUTOTITLE](/admin/managing-iam/understanding-iam-for-enterprises/about-enterprise-managed-users#identity-management-systems)."{% else %}"[AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/user-provisioning-with-scim-on-ghes#supported-identity-providers)."{% endif %}
 
+{% ifversion ghes %}
+
+## Who needs to follow these instructions?
+
+Even if your instance already uses SAML authentication, or if you were enrolled in the SCIM private beta on a previous {% data variables.product.prodname_ghe_server %} version, you must ensure you have followed **all instructions in this guide** to enable SCIM in version 3.14 and later.
+
+This guide applies in any of the following situations.
+
+* You're **setting up SAML and SCIM for the first time**: you'll follow these instructions to get started.
+* You **already use SAML authentication**: you'll need to enable SCIM on your instance, plus either reconfigure SAML with an IdP application that supports automated provisioning or set up a SCIM integration with the REST API.
+* You were **enrolled in the SCIM private beta**: you'll need to reenable SCIM on your instance and, if you're using a partner IdP, reconfigure your settings on an updated IdP application.
+
+{% endif %}
+
 {% ifversion ghec %}
 
 ## About user lifecycle management with SCIM
@@ -86,7 +100,7 @@ To ensure you can continue to sign in and configure settings when SCIM is enable
 
 > [!NOTE] Complete this section if either of the following situations applies:
 > * If you have **not already enabled SAML authentication**, you will need to do so before you can enable SCIM.
-> * If you already use SAML authentication and want to use a **partner IdP for both authentication and provisioning**, you must configure SAML using an application that supports automatic provisioning via SCIM.
+> * If you already use SAML authentication and want to use a **partner IdP for both authentication and provisioning**, or if you're **upgrading from the SCIM private beta**, you must reconfigure SAML using a new application.
 
 1. Sign in to your instance as a user with access to the Management Console.
 1. Go to the "Authentication" section of the Management Console. For instructions, see "[AUTOTITLE](/admin/managing-iam/using-saml-for-enterprise-iam/configuring-saml-single-sign-on-for-your-enterprise#configuring-saml-sso)."

content/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps.md

@@ -62,7 +62,7 @@ Some examples of automations you could create with a {% data variables.product.p
 If you want your app to take actions on behalf of itself, rather than a user, you should use an installation access token for authentication. This type of request is sometimes called "server-to-server," and it means that the app will be limited by the permissions that have been given to the app. For more information, see "[AUTOTITLE](/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app-installation)."
 
 Some examples of automations you could create with a {% data variables.product.prodname_github_app %}, where the app acts on its own behalf, include:
-* A {% data variables.product.prodname_github_app %} that uses webhooks to react to an event given a certain set of criteria. {% ifversion pat-v2 %}For example, you could create an automation around the REST API endpoints for [reviewing requests for {% data variables.product.pat_v2 %}](/rest/orgs/personal-access-tokens?apiVersion=2022-11-28#review-requests-to-access-organization-resources-with-fine-grained-personal-access-tokens) that approves a request given a certain policy.{% else %}For example, you could create an automation that uses [the REST API endpoints for labels](/rest/issues/labels) to add a label to each new issue created in a repository, given a certain set of criteria.{% endif %}
+* A {% data variables.product.prodname_github_app %} that uses webhooks to react to an event given a certain set of criteria. For example, you could create an automation around the REST API endpoints for [reviewing requests for {% data variables.product.pat_v2 %}](/rest/orgs/personal-access-tokens?apiVersion=2022-11-28#review-requests-to-access-organization-resources-with-fine-grained-personal-access-tokens) that approves a request given a certain policy.
 * A {% data variables.product.prodname_github_app %} that helps repository contributors. For example, the app could post helpful resources after a contributor creates a pull request or makes a comment.
 * A {% data variables.product.prodname_github_app %} that generates short-lived tokens to give to other CI/CD tools, or to pull information from a repository.
 

content/apps/github-marketplace/creating-apps-for-github-marketplace/requirements-for-listing-an-app.md

@@ -38,7 +38,7 @@ All listings should meet the following requirements, regardless of whether they
 * Listings must have a relevant description of the application.
 * Listings must specify a pricing plan.
 * Apps must provide value to customers and integrate with the platform in some way beyond authentication.
-* Apps must be publicly available in {% data variables.product.prodname_marketplace %} and cannot be in beta or available by invite only.
+* Apps must be publicly available in {% data variables.product.prodname_marketplace %} and cannot be in beta or available by invite only, with the exception of {% data variables.product.prodname_copilot_extensions_short %}.
 * Apps must have webhook events set up to notify the publisher of any plan changes or cancellations using the {% data variables.product.prodname_marketplace %} API. For more information, see "[AUTOTITLE](/apps/github-marketplace/using-the-github-marketplace-api-in-your-app)."
 
 For more information on providing a good customer experience, see "[AUTOTITLE](/apps/github-marketplace/creating-apps-for-github-marketplace/customer-experience-best-practices-for-apps)."
@@ -55,9 +55,24 @@ To protect your customers, we recommend that you also follow security best pract
 
 {% data reusables.marketplace.free-apps-encouraged %}
 
+## Requirements for {% data variables.product.prodname_copilot_extensions %}
+
+{% data variables.product.prodname_copilot_extensions_short %} are essentially {% data variables.product.prodname_github_apps %} with additional read access to {% data variables.product.prodname_copilot_chat_short %}, integration with the {% data variables.product.prodname_copilot_short %} API, and optional integration into other LLMs.
+
+To publish an extension, it must be owned by an organization account with Verified Creator status. For more information about the verification process or transferring ownership of your app, see "[AUTOTITLE](/apps/github-marketplace/github-marketplace-overview/applying-for-publisher-verification-for-your-organization)."
+
+The requirements to publish a {% data variables.product.prodname_copilot_extension_short %} are the same as the requirements for free apps, with the following exceptions:
+* Your extension must provide a clear and descriptive response to a prompt like "What can you do?" or "List your capabilities".
+* Your extension can be in beta as long as that is clearly communicated in the listing description. If you are using a waitlist, you must also include a link to sign up at the top of the description. Someone from the {% data variables.product.github %} review team will join the waitlist and email your technical lead requesting access for testing.
+* You must include links to two videos that demonstrate the following:
+    * A few example prompts and responses from your extension
+    * A net new user installing, authenticating, and sending their first prompt to your extension. These videos are private to {% data variables.product.github %} and are used solely for reviewing your listing submission. It's okay if the videos are brief and unedited.
+* Your extension must provide a stable and reliable user experience, and be able to perform the capabilities listed in the description.
+* A pathway must be provided for new users to install, setup and authorize your extension with minimal friction. If the {% data variables.product.github %} review team is not able to successfully onboard to your extension for testing, it will not be approved for publishing.
+
 ## Requirements for paid apps
 
-To publish a paid plan for your app on {% data variables.product.prodname_marketplace %}, your app must be owned by an organization that is a verified publisher. For more information about the verification process or transferring ownership of your app, see "[AUTOTITLE](/apps/github-marketplace/github-marketplace-overview/applying-for-publisher-verification-for-your-organization)."
+To publish a paid plan for your app on the {% data variables.product.prodname_marketplace %}, your app must be owned by an organization that is a verified publisher. For more information about the verification process or transferring ownership of your app, see "[AUTOTITLE](/apps/github-marketplace/github-marketplace-overview/applying-for-publisher-verification-for-your-organization)."
 
 If your app is already published and you're a verified publisher, then you can publish a new paid plan from the pricing plan editor. For more information, see "[AUTOTITLE](/apps/github-marketplace/listing-an-app-on-github-marketplace/setting-pricing-plans-for-your-listing)."
 
@@ -79,7 +94,7 @@ When you are ready to publish the app on {% data variables.product.prodname_mark
 
 Your app does not need to handle payments but does need to use {% data variables.product.prodname_marketplace %} purchase events to manage new purchases, upgrades, downgrades, cancellations, and free trials. For information about how integrate these events into your app, see "[AUTOTITLE](/apps/github-marketplace/using-the-github-marketplace-api-in-your-app)."
 
-Using GitHub's billing API allows customers to purchase an app without leaving GitHub and to pay for the service with the payment method already attached to their account on {% data variables.product.github %}.
+Using {% data variables.product.github %}'s billing API allows customers to purchase an app without leaving {% data variables.product.github %} and to pay for the service with the payment method already attached to their account on {% data variables.product.github %}.
 
 * Apps must support both monthly and annual billing for paid subscriptions purchases.
 * Listings may offer any combination of free and paid plans. Free plans are optional but encouraged. For more information, see "[AUTOTITLE](/apps/github-marketplace/listing-an-app-on-github-marketplace/setting-pricing-plans-for-your-listing)."

content/authentication/authenticating-with-saml-single-sign-on/authorizing-a-personal-access-token-for-use-with-saml-single-sign-on.md

@@ -12,7 +12,7 @@ topics:
   - SSO
 shortTitle: '{% data variables.product.pat_generic_caps %} with SAML'
 ---
-You must authorize your {% data variables.product.pat_v1 %} after creation before the token can access an organization that uses SAML single sign-on (SSO). For more information about creating a new {% data variables.product.pat_v1 %}, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)."{% ifversion pat-v2 %} {% data variables.product.pat_v2_caps %}s are authorized during token creation, before access to the organization is granted.{% endif %}
+You must authorize your {% data variables.product.pat_v1 %} after creation before the token can access an organization that uses SAML single sign-on (SSO). For more information about creating a new {% data variables.product.pat_v1 %}, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)." {% data variables.product.pat_v2_caps %}s are authorized during token creation, before access to the organization is granted.
 
 {% data reusables.saml.must-authorize-linked-identity %}