Merge pull request #43648 from github/repo-sync

Repo sync

Author: docs-bot

content/actions/how-tos/manage-runners/use-proxy-servers.md

@@ -32,6 +32,10 @@ On Windows machines, the proxy environment variable names are case-insensitive.
 
 {% data reusables.actions.self-hosted-runner-ports-protocols %}
 
+> [!WARNING]
+> Self-hosted runners do not support using IP addresses in the `no_proxy` environment variable. If your {% data variables.product.prodname_ghe_server %} instance uses an IP address and you configure `no_proxy` to bypass the proxy for that address, the runner will still fail to connect.
+> If your {% data variables.product.prodname_ghe_server %} instance is accessed using an IP address and the connection must bypass the proxy, the runner will fail to connect, even if that IP address is listed in `no_proxy`.
+
 ### Example configurations
 
 {% data reusables.actions.environment-variables-as-case-sensitive %}

content/billing/reference/github-license-users.md

@@ -37,6 +37,7 @@ category:
 * Billing managers
 * Anyone with a pending invitation to become a billing manager
 * Anyone with a pending invitation to become an outside collaborator on a public repository owned by your organization
+* Anyone with a failed invitation to become an organization member or an outside collaborator on a repository owned by your organization
 
 ## Organizations on {% data variables.product.prodname_ghe_cloud %}
 
@@ -53,19 +54,21 @@ category:
 If your enterprise does not use {% data variables.product.prodname_emus %}, you will also be billed for each of the following accounts:
 
 * Anyone with a pending invitation to become an organization owner or member
+  * If the invited user already consumes an enterprise license, a pending organization invitation won't use an additional license—as long as the invitation is sent to their {% data variables.product.github %} username or a verified email address on their account. 
 * Anyone with a pending invitation to become an outside collaborator on private or internal repositories owned by your organization, excluding forks
   * {% data reusables.organizations.org-invite-scim %}
-  * Inviting an outside collaborator to a repository using their email address temporarily uses an available seat, even if they already have access to other repositories. After they accept the invite, the seat will be freed up again. Inviting them using their username does not temporarily use a seat.
+  * If the invited user already consumes an enterprise license because they're a collaborator on an internal or private repository in the enterprise, a pending collaborator invitation using their email address for another repository in the enterprise consumes an available seat. After they accept the invite, the seat will be freed up again. Inviting them using their username does not temporarily use a seat.
 
 ### People who don't consume licenses
 
-* {% data variables.enterprise.prodname_managed_users_caps %} that are suspended
+* Suspended {% data variables.enterprise.prodname_managed_users_caps %}
 * Enterprise owners who are not a member or owner of at least one organization in the enterprise
 * The user who set up the enterprise
 * Enterprise billing managers
 * Billing managers for individual organizations
 * Anyone with a pending invitation to become a billing manager
 * Anyone who is an outside collaborator on a public repository owned by your organization, or who has a pending invitation to become one
+* Anyone with a failed invitation to become an organization member or an outside collaborator on a repository owned by your organization
 * Guest collaborators who are not organization members or repository collaborators (see [AUTOTITLE](/enterprise-cloud@latest/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise#guest-collaborators))
 * Users of {% data variables.visual_studio.prodname_vss_ghe %} whose accounts on {% data variables.product.prodname_dotcom %} are not linked, and who do not meet any of the other criteria for per-user pricing
 * Unaffiliated users: people who have been added to the enterprise, but are not members of any organizations in the enterprise

content/code-security/concepts/security-at-scale/best-practices-for-selecting-pilot-repositories.md

@@ -0,0 +1,95 @@
+---
+title: Best practices for selecting pilot repositories
+shortTitle: Select pilot repositories
+intro: 'The right pilot repositories demonstrate value quickly and prepare your organization for broader enablement of {% data variables.product.prodname_GH_secret_protection %}.'
+versions:
+  fpt: '*'
+  ghec: '*'
+  ghes: '*'
+contentType: concepts
+---
+
+Before enabling {% data variables.product.prodname_GH_secret_protection %} organization-wide, run a pilot to validate the solution with a small set of repositories. A pilot helps you refine your rollout strategy, identify workflow adjustments, and demonstrate security value to stakeholders. This article will help you choose the best repositories for your pilot.
+
+A successful pilot requires strategic repository selection. The repositories you choose determine how quickly you can demonstrate value, gather actionable feedback, and prepare for organization-wide adoption.
+
+## Selection criteria
+
+A successful pilot requires strategic repository selection. The repositories you choose determine how quickly you can demonstrate value, gather actionable feedback, and prepare for organization-wide adoption.
+
+When choosing repositories, consider the following criteria.
+
+### Active development and team engagement
+
+Your pilot needs repositories that generate timely feedback on how {% data variables.product.prodname_secret_protection %} fits into daily development work.
+
+* Select repositories with **regular commits and pull requests**. Active repositories generate feedback quickly and show how {% data variables.product.prodname_secret_protection %} fits into real development workflows.
+* Choose **teams** that will engage with the pilot. Responsive maintainers will identify workflow adjustments faster and help refine your rollout strategy.
+* **Use repository properties** to systematically identify repositories by team, criticality, or other custom attributes. See [AUTOTITLE](/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization).
+
+### Known secret exposure
+
+{% ifversion secret-risk-assessment %}
+
+Choose repositories flagged in your secret risk assessment. These repositories are ideal pilot candidates because they demonstrate immediate value by showing secrets that need remediation.
+
+{% else %}
+
+Choose repositories you suspect contain secrets based on past incidents or security reviews. These repositories are ideal pilot candidates because they allow you to validate the tool's effectiveness quickly.
+
+{% endif %}
+
+Prioritize repositories with production credentials, infrastructure configurations, or integrations with critical services. These high-value targets demonstrate the security value of {% data variables.product.prodname_secret_protection %}.
+
+### Technical diversity
+
+Your pilot should validate that {% data variables.product.prodname_secret_protection %} works with your programming languages and tools.
+
+* Include repositories using different programming languages and frameworks. This validates {% data variables.product.prodname_secret_protection %} coverage across your codebase.
+* Select repositories with CI/CD pipelines to identify potential deployment impacts early. Understanding these interactions prevents surprises during broader rollout.
+
+### Organizational representation
+
+A successful pilot requires buy-in from different parts of your organization.
+
+* Choose repositories from different teams or business units. Diverse feedback reveals patterns that wouldn't emerge from a single team's experience.
+* Include at least one repository that leadership cares about. Executive visibility maintains pilot momentum and facilitates future budget discussions.
+
+### Repositories to avoid initially
+
+Not all repositories make good pilot candidates.
+
+* **Low-activity or archived repositories**: You won't get timely workflow feedback.
+* **Experimental or personal repositories**: These repositories don't reflect production patterns.
+* **Repositories with complex custom tooling**: Unusual workflows may complicate feedback.
+* **Mission-critical repositories with zero change tolerance**: It's best to add these repositories _after_ validating the solution.
+
+## Pilot size by organization
+
+Once you've identified repositories that meet these criteria, determine the size of your pilot. The right pilot size balances gathering sufficient feedback with avoiding team overwhelm.
+
+| Organization size | Number of repositories | Recommendations |
+|---|---|---|
+| **Small** (under 100 developers) | 3-5 repositories | Start with your most critical projects. |
+| **Medium** (100-500 developers) | 5-10 repositories | Select repositories across different teams, including a mix of high-activity and moderate-activity repositories. |
+| **Large** (500+ developers) | 10-20 repositories | Ensure broad representation across the organization. Consider a phased approach with waves of repository additions. |
+
+## Before enabling your pilot
+
+Take these steps to set your pilot up for success.
+
+* Confirm repository owners agree to participate. Unwilling teams generate negative feedback that doesn't reflect actual product issues.
+* Identify champions within each pilot team. Champions answer questions and keep feedback flowing.
+* Document baseline metrics like commit frequency and contributor count. These baselines help you measure pilot impact.
+
+## Further reading
+
+* [Identify repositories for secret protection](https://support.github.com/product-guides/github-advanced-security-secret-protection/get-started/identify-repositories-for-secret-protection) in the GitHub Advanced Security product guides
+
+{% ifversion secret-risk-assessment %}
+
+## Next steps
+
+Now that you've selected your pilot repositories, review pricing and configure {% data variables.product.prodname_GH_secret_protection %}. See [AUTOTITLE](/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/protect-your-secrets).
+
+{% endif %}

content/code-security/concepts/security-at-scale/index.md

@@ -8,6 +8,7 @@ versions:
   ghec: '*'
 contentType: concepts
 children:
+  - /best-practices-for-selecting-pilot-repositories
   - /about-enabling-security-features-at-scale
   - /about-security-overview
   - /about-security-campaigns

content/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/protect-your-secrets.md

@@ -16,7 +16,10 @@ category:
 
 ## Prerequisites
 
-Before you configure {% data variables.product.prodname_GH_secret_protection %}, you should run the free {% data variables.product.prodname_secret_risk_assessment %} to inform your enablement strategy. See [AUTOTITLE](/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/assess-your-secret-risk).
+Before you configure {% data variables.product.prodname_GH_secret_protection %}:
+
+* Run the free {% data variables.product.prodname_secret_risk_assessment %} to inform your enablement strategy. See [AUTOTITLE](/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/assess-your-secret-risk).
+* Review best practices for choosing pilot repositories. See [AUTOTITLE](/code-security/concepts/security-at-scale/best-practices-for-selecting-pilot-repositories).
 
 ## Configuring {% data variables.product.prodname_GH_secret_protection %}
 

content/code-security/tutorials/secure-your-organization/interpreting-secret-risk-assessment-results.md

@@ -93,4 +93,4 @@ Finally, look for the following indicators, which may require additional prevent
 
 ## Next steps
 
-For stronger secret security and additional insights, {% data variables.product.github %} recommends enabling {% data variables.product.prodname_GH_secret_protection %} for all of your repositories. See [AUTOTITLE](/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/protect-your-secrets).
+After understanding your secret exposure, select repositories for a {% data variables.product.prodname_GH_secret_protection %} pilot. See [AUTOTITLE](/code-security/concepts/security-at-scale/best-practices-for-selecting-pilot-repositories).

content/contributing/writing-for-github-docs/templates.md

@@ -109,9 +109,9 @@ Optionally, include a bulleted list of related articles the user can reference t
 
 <!-- markdownlint-enable search-replace -->
 
-## Procedural article template
+## How-to article template
 
-Use the content model for full instructions and examples on how to write procedural content. For more information, see [AUTOTITLE](/contributing/style-guide-and-content-model/procedural-content-type).
+Use the content model for full instructions and examples on writing how-to content. For more information, see [AUTOTITLE](/contributing/style-guide-and-content-model/how-to-content-type).
 
 <!-- markdownlint-disable search-replace -->
 
@@ -127,7 +127,7 @@ versions:
 ---
 
 {% comment %}
-Follow the guidelines in https://docs.github.com/contributing/writing-for-github-docs/content-model#procedural to write this article.-- >
+Follow the guidelines in https://docs.github.com/contributing/writing-for-github-docs/content-model to write this article.
 Great intros give readers a quick understanding of what's in the article, so they can tell whether it's relevant to them before moving ahead. For more tips, see https://docs.github.com/contributing/writing-for-github-docs/content-model
 For product callout info, see https://github.com/github/docs/tree/main/content#product
 For product version instructions, see https://github.com/github/docs/tree/main/content#versioning

content/copilot/concepts/agents/coding-agent/about-custom-agents.md

@@ -9,54 +9,9 @@ category:
 contentType: concepts
 ---
 
-## About {% data variables.copilot.custom_agents_short %}
+{% data reusables.copilot.copilot-cli.custom-agents-about-intro %}
 
-{% data variables.copilot.custom_agents_caps_short %} are specialized versions of the {% data variables.product.prodname_copilot_short %} agent that you can tailor to your unique workflows, coding conventions, and use cases. They act like tailored teammates that follow your standards, use the right tools, and implement team-specific practices. You define these agents once instead of repeatedly providing the same instructions and context.
-
-You define {% data variables.copilot.custom_agents_short %} using Markdown files called {% data variables.copilot.agent_profiles %}. These files specify prompts, tools, and MCP servers. This allows you to encode your conventions, frameworks, and desired outcomes directly into {% data variables.product.prodname_copilot_short %}.
-
-The {% data variables.copilot.agent_profile %} defines the {% data variables.copilot.copilot_custom_agent_short %}'s behavior. When you assign the agent to a task or issue, it instantiates the {% data variables.copilot.copilot_custom_agent_short %}.
-
-## {% data variables.copilot.agent_profile_caps %} format
-
-{% data variables.copilot.agent_profiles_caps %} are Markdown files with YAML frontmatter. In their simplest form, they include:
-
-* **Name**: A unique identifier for the {% data variables.copilot.copilot_custom_agent_short %}.
-* **Description**: Explains the agent's purpose and capabilities.
-* **Prompt**: Custom instructions that define the agent's behavior and expertise.
-* **Tools** (optional): Specific tools the agent can access. By default, agents can access all available tools, including built-in tools and MCP server tools.
-
-{% data variables.copilot.agent_profiles_caps %} can also include MCP server configurations using the `mcp-server` property.
-
-### Example {% data variables.copilot.agent_profile %}
-
-This example is a basic {% data variables.copilot.agent_profile %} with name, description, and prompt configured.
-
-```text
----
-name: readme-creator
-description: Agent specializing in creating and improving README files
----
-
-You are a documentation specialist focused on README files. Your scope is limited to README  files or other related documentation files only - do not modify or analyze code files.
-
-Focus on the following instructions:
-- Create and update README.md files with clear project descriptions
-- Structure README sections logically: overview, installation, usage, contributing
-- Write scannable content with proper headings and formatting
-- Add appropriate badges, links, and navigation elements
-- Use relative links (e.g., `docs/CONTRIBUTING.md`) instead of absolute URLs for files within the repository
-- Make links descriptive and add alt text to images
-```
-
-## Where you can configure {% data variables.copilot.custom_agents_short %}
-
-You can define {% data variables.copilot.agent_profiles %} at different levels:
-
-* **Repository level**: Create `.github/agents/CUSTOM-AGENT-NAME.md` in your repository for project-specific agents.
-* **Organization or enterprise level**: Create `/agents/CUSTOM-AGENT-NAME.md` in a `.github-private` repository for broader availability.
-
-For more information, see [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents) and [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/prepare-for-custom-agents).
+{% data reusables.copilot.copilot-cli.custom-agents-about-details %}
 
 ## Where you can use {% data variables.copilot.custom_agents_short %}