Merge pull request #44911 from github/repo-sync

Repo sync

Author: docs-bot

.github/agents/driver-writer.md

@@ -0,0 +1,71 @@
+---
+
+name: "Driver-Writer"
+description: "Use when writing, editing, or reviewing content for the Driver persona: enterprise administrators, platform engineers, billing managers, security leads, and others who enable developers at scale."
+tools: ['read', 'edit/editFiles', 'search']
+
+---
+
+# Driver-Writer Agent
+
+You are a writing assistant for the GitHub Docs team. You help writers create, edit, and review documentation that serves the **Driver persona**.
+
+A Driver is any GitHub user who supports the work of multiple developers by making changes to GitHub at scale. They remove barriers and enable developers to work efficiently while providing guardrails for compliance and security. Drivers include enterprise administrators, billing managers, application security leads, CI/CD administrators, tech leads, and OS maintainers.
+
+Our team prioritizes **self-serve enterprise customers** that use GitHub Enterprise but are not large enough to get dedicated support from a GitHub sales or success team. These customers rely heavily on documentation to set up and manage their enterprise. When making content decisions, optimize for this audience.
+
+Drivers come from two broad backgrounds, and content should account for both:
+
+* **IT administration**: Expects process and controls based on experience with other enterprise systems. May use terminology from other platforms when searching for information.
+* **Development**: Fewer preconceptions about enterprise administration. May have limited knowledge of best practices for setting up large systems.
+
+## What makes Driver content different
+
+Driver content is distinct from developer-focused (Builder) content in a few key ways. Apply these when writing or editing:
+
+### Frame value in terms of the enterprise, not individual productivity
+
+Builder content connects features to the developer's own workflow. Driver content should connect features to what Drivers care about: compliance, security posture, cost management, developer enablement at scale, and reducing operational risk.
+
+* Instead of: "You can restrict email notifications for your enterprise."
+* Write: "You can prevent your enterprise's information from leaking into personal email accounts."
+
+### Help Drivers make confident decisions
+
+Drivers often face choices with long-lasting, hard-to-reverse consequences (e.g., choosing between EMU and classic authentication, selecting an identity provider, structuring enterprises and organizations). Content should present enough context for the reader to choose confidently: what the tradeoffs are, what most enterprises do, and what cannot be changed later.
+
+### Write for people who manage GitHub, not people who use it to code
+
+Drivers are configuring, monitoring, and governing, not writing code. They are less likely to want code examples and more likely to need:
+
+* Clear explanations of how settings interact and propagate across an enterprise
+* Guidance on rollout sequence and dependencies between configuration steps
+* Visibility into what their developers will experience as a result of their changes
+
+### Be explicit about policy scope and cascade
+
+When writing about enterprise settings or policies, always clarify what level the setting operates at (enterprise, organization, repository) and how it cascades. Make it clear who controls the setting and whether lower levels can override it. When parallel articles exist for different levels (e.g., enterprise vs. org), keep the structure, terminology, and level of detail consistent between them.
+
+### Flag specific high-risk claims for verification
+
+Driver actions often affect an entire enterprise and can be hard to reverse, so a single inaccurate detail can have outsized consequences: a security gap, a compliance failure, unexpected cost, or an administrator locking themselves out. Do not flag an entire article as high-risk just because of its topic. Instead, identify the specific claims most likely to cause harm if wrong, and call each one out individually for the writer to verify.
+
+Pay closest attention to discrete, checkable claims in these areas:
+
+* Authentication and identity (e.g., specific SAML/SCIM attribute values, SSO setup steps)
+* Security and compliance policy behavior and enforcement
+* Billing, licensing, and spending controls (specific numbers, thresholds, what counts toward usage)
+* Irreversible or enterprise-wide configuration steps
+* Exact permission or role requirements for an action
+
+For example, in an article about configuring SSO, do not say "verify this entire article." Instead, flag the specific risky claims, e.g.: "Step 6 says to set the SAML `NameID` to the user's email. Confirm the exact required attribute with the identity team, since the wrong value will block all sign-ins."
+
+## Driver user journey
+
+Drivers move through these phases with GitHub. Content should meet them where they are:
+
+* **Evaluate**: Researching tools that add value for the team.
+* **Onboard**: Understanding best practices to configure the enterprise. Relying on documentation before reaching out to people.
+* **Adopt**: Monitoring rollout, managing licenses, evaluating ROI.
+* **Optimize**: Monitoring data, auditing configuration for efficiency.
+* **Sustain**: Promoting best practices, making minimal configuration changes.

.github/workflows/changelog-agent.yml

@@ -591,7 +591,7 @@ jobs:
               body: prBody,
               head: branchName,
               base: 'main',
-              draft: true,
+              draft: false,
             });
 
             // Add labels
@@ -600,22 +600,22 @@ jobs:
                 owner: 'github',
                 repo: 'docs-content',
                 issue_number: pullRequest.number,
-                labels: ['ready-for-doc-review', 'skip FR board', 'llm-generated'],
+                labels: ['skip FR board', 'llm-generated'],
               });
             } catch (err) {
               core.warning(`Failed to add labels: ${err.message}`);
             }
 
-            // Assign to PR author
+            // Request review from PR author
             try {
-              await github.rest.issues.addAssignees({
+              await github.rest.pulls.requestReviewers({
                 owner: 'github',
                 repo: 'docs-content',
-                issue_number: pullRequest.number,
-                assignees: [process.env.PR_AUTHOR],
+                pull_number: pullRequest.number,
+                reviewers: [process.env.PR_AUTHOR],
               });
             } catch (err) {
-              core.warning(`Failed to assign PR to @${process.env.PR_AUTHOR}: ${err.message}`);
+              core.warning(`Failed to request review from @${process.env.PR_AUTHOR}: ${err.message}`);
             }
 
             core.setOutput('changelog_pr_url', pullRequest.html_url);

content/admin/monitoring-and-managing-your-instance/configuring-high-availability/elasticsearch-cross-cluster-replication.md

@@ -0,0 +1,96 @@
+---
+title: Configuring Elasticsearch Cross-Cluster Replication for high availability
+shortTitle: Elasticsearch Cross-Cluster Replication
+intro: 'You can make search more resilient during maintenance, failovers, and upgrades on a high availability deployment by enabling Elasticsearch Cross-Cluster Replication (CCR).'
+versions:
+  ghes: '>=3.19'
+contentType: how-tos
+category:
+  - Scale your instance
+---
+
+## About Elasticsearch Cross-Cluster Replication
+
+{% data variables.product.prodname_ghe_server %} uses Elasticsearch to power search across issues, pull requests, repositories, the projects and releases pages, and the counts shown throughout the web interface. Because search is central to the product, the reliability of Elasticsearch directly affects the day-to-day administration of your instance.
+
+In a high availability (HA) configuration, {% data variables.product.prodname_ghe_server %} uses a leader/follower model. The primary appliance receives all writes and traffic, and replica appliances stay in sync as read-only standbys that can take over if the primary fails. For more information, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-high-availability/about-high-availability-configuration).
+
+In earlier releases, Elasticsearch did not support this leader/follower model directly. To replicate search data, {% data variables.product.prodname_ghe_server %} ran a single Elasticsearch cluster that spanned the primary and replica appliances. This approach worked, but it introduced a class of problems: Elasticsearch could move a primary shard (the shard responsible for receiving and validating writes) onto a replica appliance. If that replica was then taken offline for maintenance, the instance could enter a locked state, because the replica waited for Elasticsearch to become healthy while Elasticsearch could not become healthy until the replica rejoined.
+
+Elasticsearch Cross-Cluster Replication (CCR) removes this dependency. Instead of one cluster spanning every appliance, each appliance runs as an independent single-node Elasticsearch cluster. CCR then replicates index data between these clusters using a natively supported leader/follower pattern. Data is copied only after it has been durably persisted to the underlying Lucene segments, so replicas always follow data that has been safely written. As a result, a critical primary shard can no longer end up stranded on a read-only replica.
+
+### Benefits
+
+* **Fewer locked upgrades and maintenance windows.** Removing the circular dependency between the primary and replica appliances during maintenance reduces the risk of an instance becoming stuck.
+* **Stronger data protection.** Data is replicated only after it is durably saved, which helps prevent index corruption during failovers.
+* **Simpler operations.** The pattern reduces the need for manual index repairs that previously occurred when maintenance steps were performed out of order.
+
+### Availability
+
+Elasticsearch CCR is supported beginning with {% data variables.product.prodname_ghe_server %} 3.19.1. The feature is optional. {% data variables.product.company_short %} plans to make CCR the default HA search architecture over the following two years, so you have time to test it and provide feedback before it becomes the default.
+
+## Requirements
+
+Before you enable CCR, confirm the following.
+
+* Your instance runs {% data variables.product.prodname_ghe_server %} 3.19.1 or later.
+* Your instance is configured for high availability with at least two appliances (a primary and one or more replicas).
+* You have an updated {% data variables.product.prodname_ghe_server %} license that includes the Elasticsearch entitlement required for CCR. Contact {% data variables.contact.contact_enterprise_sales %} or {% data variables.contact.github_support %} to have your enterprise enabled for the new license, then download the updated license file.
+
+{% warning %}
+
+**Warning:** When CCR is enabled, the upgrade preflight check requires a valid CCR-enabled license. If the flag is enabled and the license check fails, the upgrade will not proceed. Make sure your updated license is installed before you enable the feature or upgrade. If you are unsure whether your license includes the Elasticsearch entitlement, contact {% data variables.contact.github_support %}.
+
+{% endwarning %}
+
+## Enabling Elasticsearch Cross-Cluster Replication
+
+{% note %}
+
+**Note:** The migration may take a significant amount of time depending on the size of your instance, because search data is consolidated onto the primary before replication restarts. Plan to enable CCR during a maintenance window, and test the process in a non-production environment first. For more information, see [AUTOTITLE](/admin/upgrading-your-instance).
+
+{% endnote %}
+
+1. Contact {% data variables.contact.github_support %} and request access to the new HA search architecture. {% data variables.product.company_short %} will enable your enterprise so that you can download the required CCR-enabled license.
+1. Download your updated license and upload it to your instance. For more information, see [AUTOTITLE](/admin/overview/managing-your-github-enterprise-license).
+1. On the primary appliance, enable the feature.
+
+   ```shell
+   ghe-config app.elasticsearch.ccr true
+   ```
+
+1. Apply the configuration by running a configuration run, or by upgrading the instance to 3.19.1 or later.
+
+   ```shell
+   ghe-config-apply
+   ```
+
+1. When the instance restarts, Elasticsearch migrates the installation to the new replication method. This migration consolidates search data onto the primary, ends the cluster that previously spanned appliances, and restarts replication using CCR. During the migration, {% data variables.product.prodname_ghe_server %} attaches followers to your existing search indexes and enables an auto-follow rule so that any indexes created in the future are followed automatically.
+
+## Using Elasticsearch Cross-Cluster Replication
+
+### Verifying replication
+
+After the migration completes, search continues to function normally and no change is required in how users search. To confirm replication health, generate a support bundle, which includes CCR status information for review. For more information, see [AUTOTITLE](/support/contacting-github-support/providing-data-to-github-support).
+
+### Failover and disaster recovery
+
+You continue to use the standard high availability replication utilities to manage replicas and to fail over. For more information, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-high-availability/initiating-a-failover-to-your-replica-appliance) and [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-high-availability/recovering-a-high-availability-configuration).
+
+After a failover with CCR enabled, the promoted appliance becomes the new leader for search, and replicas re-follow its indexes as part of the standard recovery process. If you encounter errors related to search replication during or after a failover, contact {% data variables.contact.github_support %}.
+
+### Disabling Elasticsearch Cross-Cluster Replication
+
+{% warning %}
+
+**Warning:** Do not disable CCR on a production instance without guidance from {% data variables.contact.github_support %}. Disabling CCR is not a routine self-service operation. Turning the feature off can trigger removal of replica Elasticsearch data as part of returning to the previous mode.
+
+{% endwarning %}
+
+If you need to return to the previous search architecture, contact {% data variables.contact.github_support %} before making any changes. {% data variables.product.company_short %} will help you confirm that your license, replication state, and upgrade path are handled safely.
+
+## Further reading
+
+* [AUTOTITLE](/admin/monitoring-and-managing-your-instance/configuring-high-availability/about-high-availability-configuration)
+* [AUTOTITLE](/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities)
+* [How we rebuilt the search architecture for high availability in GitHub Enterprise Server](https://github.blog/engineering/architecture-optimization/how-we-rebuilt-the-search-architecture-for-high-availability-in-github-enterprise-server/) on the {% data variables.product.prodname_blog %}

content/admin/monitoring-and-managing-your-instance/configuring-high-availability/index.md

@@ -13,6 +13,7 @@ versions:
   ghes: '*'
 children:
   - /about-high-availability-configuration
+  - /elasticsearch-cross-cluster-replication
   - /answers-to-common-questions-about-high-availability-replicas
   - /creating-a-high-availability-replica
   - /monitoring-a-high-availability-configuration

content/billing/concepts/cost-centers.md

@@ -17,7 +17,9 @@ Cost centers allow you to attribute usage and spending to business units, improv
 * **Enterprise owners and billing managers** can create and edit cost centers for **any resource**.
 * **Organization owners** can create and edit cost centers that contain **resources in their organization**.
 
-When you create a cost center, you define which resources it contains from users, repositories, and organizations. If your account is billed through Azure, you can also add an Azure subscription to bill usage to a different Azure subscription than the enterprise default.
+When you create a cost center, you define which resources it contains from users, repositories, organizations, and enterprise teams. If your account is billed through Azure, you can also add an Azure subscription to bill usage to a different Azure subscription than the enterprise default.
+
+{% data reusables.billing.enterprise-teams-in-cost-centers %}
 
 To get started with cost centers, see [AUTOTITLE](/billing/tutorials/control-costs-at-scale).
 

content/billing/how-tos/products/use-cost-centers.md

@@ -23,16 +23,18 @@ category:
 > [!NOTE]
 > An enterprise can create up to 500 cost centers.
 
-Create cost centers to monitor and manage expenses for specific organizations or repositories. Multiple organizations, repositories, and users can be assigned to one cost center.
+Create cost centers to monitor and manage expenses for specific organizations or repositories. Multiple organizations, repositories, users, and enterprise teams can be assigned to one cost center.
 
-When you create a cost center, you can add **organizations**, **repositories**, or **users**. The cost center will then track spending for the selected entities.
+When you create a cost center, you can add **organizations**, **repositories**, **users**, or **enterprise teams**. The cost center will then track spending for the selected entities.
+
+{% data reusables.billing.enterprise-teams-in-cost-centers %}
 
 {% data reusables.enterprise-accounts.access-enterprise %}
 {% data reusables.billing.enterprise-billing-menu %}
 {% data reusables.billing.cost-center-click-new %}
 1. In the text box under "Name", enter a name for your cost center.
 1. If your account is billed to Azure, you have the option to add an Azure ID. Your credentials will be verified against Azure to ensure the Azure IDs associated to your account are available.
-1. Under **Resources**, select the organizations, repositories, and/or users that will be a part of the cost center.
+1. Under **Resources**, select the organizations, repositories, users, and/or enterprise teams that will be a part of the cost center.
 
    >[!NOTE] A resource (organization, repository, or user) can only be assigned to one cost center at a time. If you add a resource that belongs to a different cost center, it will be moved to the new cost center and you will be notified.
 

content/billing/reference/cost-center-allocation.md

@@ -36,8 +36,11 @@ To ensure your cost centers reflect spending as intended, it's important to unde
 | User associated with a cost center | License granted | License and product costs charged |
 |--|--|--|
 | Direct assignment | By any organization | To the **cost center** the user is assigned to. |
+| By enterprise team membership | By any organization | To the **cost center** the user's enterprise team is assigned to. Direct assignment to another cost center takes precedence; if the user is in multiple enterprise teams assigned to different cost centers, the team created first applies. |
 | By organization membership only | By an organization assigned to a cost center | To the **cost center** the organization belongs to. If the organization does not belong to a cost center, to the **enterprise**. |
 
+When you assign an enterprise team to a cost center, its members are allocated to that cost center the same way other group-based assignments are, and membership stays current automatically as people join or leave the team. If a user is also assigned to a different cost center directly, the direct assignment takes precedence. If a user belongs to more than one enterprise team, and those teams are assigned to different cost centers, the user is associated with the cost center of the enterprise team that was created first.
+
 Users who belong to multiple organizations in an enterprise or who receive a {% data variables.product.prodname_copilot_short %} license from multiple organizations:
 
 * **{% data variables.product.prodname_enterprise %}** and **{% data variables.product.prodname_GHAS %}** license usage is allocated to the oldest organization and charges are allocated to the cost center containing that organization.