diff --git a/content/admin/upgrading-your-instance/automation-via-cli-api/enterprise-server-upgrade-automation.md b/content/admin/upgrading-your-instance/automation-via-cli-api/enterprise-server-upgrade-automation.md deleted file mode 100644 index da562c0cb5e2..000000000000 --- a/content/admin/upgrading-your-instance/automation-via-cli-api/enterprise-server-upgrade-automation.md +++ /dev/null @@ -1,305 +0,0 @@ ---- -title: Enterprise Server Upgrade Automation -intro: You can use the ghes-manage API or `es` plugin to automate upgrade operations in Enterprise Server environments. -versions: - ghes: '>= 3.21' -shortTitle: Upgrade Enterprise Server -contentType: how-tos ---- - -You can upgrade a GitHub Enterprise Server instance using the Manage {% data variables.product.prodname_ghe_server %} API or the `gh es` CLI extension. These tools automate the process of downloading the upgrade package, running pre-upgrade checks, and applying the new version. - -## Prerequisites - -- Back up your data with [GitHub Enterprise Server Backup Utilities](https://github.com/github/backup-utils#readme). -- Schedule a maintenance window for end users. -- Ensure you have authentication credentials for the Manage {% data variables.product.prodname_ghe_server %} API. For more information, see [AUTOTITLE](/rest/enterprise-admin#authentication). - -## Step 1: Download the upgrade package - -Download the upgrade package to the instance. - -### Using the CLI - -```shell -# Download a specific version -gh es upgrade download --version VERSION - -# Or download the latest available version -gh es upgrade download -``` - -### Using the API - -```shell -curl -L \ - -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/download \ - -d '{"version":"VERSION"}' -``` - -## Step 2: Monitor download progress - -Confirm the download has completed before proceeding. - -### Using the CLI - -```shell -gh es upgrade download status -``` - -### Using the API - -```shell -curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/download/status -``` - -Wait until `status` shows `COMPLETED`. - -## Step 3: Apply the upgrade's pre-upgrade phase - -Apply the upgrade. This runs both the pre-upgrade and upgrade phases sequentially. - -### Using the CLI - -```shell -gh es upgrade apply --version VERSION --phase pre-upgrade -``` - -### Using the API - -```shell -curl -L \ - -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/apply \ - -d '{"version":"VERSION", "phase":"pre-upgrade}' -``` - - -## Step 4: Monitor pre-upgrade progress - -Monitor the upgrade until it completes. The instance will reboot once the upgrade finishes. - -### Using the CLI - -```shell -gh es upgrade status --verbose -``` - -### Using the API - -```shell -curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - "https://HOSTNAME:8443/manage/v1/upgrade/status?verbose=true" -``` - -Wait until `status` shows `completed` and `is_running` shows `false`. - -## Step 5: Enable maintenance mode - -Enable maintenance mode. - -### Using the CLI - - ```shell - gh es maintenance set --enabled true - ``` - -### Using the API - - ```shell - curl -L \ - -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/maintenance \ - -d '{"enabled":true}' - ``` - -## Step 6: Apply the upgrade's upgrade phase - -Apply the upgrade. This runs both the pre-upgrade and upgrade phases sequentially. - -### Using the CLI - -```shell -gh es upgrade apply --version VERSION --phase pre-upgrade -``` - -### Using the API - -```shell -curl -L \ - -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/apply \ - -d '{"version":"VERSION", "phase":"pre-upgrade}' -``` - -## Step 7: Verify and disable maintenance mode - -After the upgrade completes: - -First, confirm the release version has been updated. - -### Using the CLI - - ```shell - gh es release version - ``` - -### Using the API - - ```shell - curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/version - ``` - -Then, disable maintenance mode. - -### Using the CLI - - ```shell - gh es maintenance set --enabled false - ``` - -### Using the API - - ```shell - curl -L \ - -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/maintenance \ - -d '{"enabled":false}' - ``` - -## Upgrading a high availability deployment - -For instances with a high availability (HA) replica, the download and pre-upgrade phases are non-disruptive and can run across all nodes at once. UUID targeting is only needed for the upgrade phase itself, which triggers the reboot. This lets you control the order nodes reboot in: upgrade the replica first, then the primary. - -To retrieve node UUIDs, run `gh es config get-metadata` or query `GET /manage/v1/config/nodes`. - -### Using the CLI - -```shell -# Download the package to all nodes -gh es upgrade download --version VERSION - -# Wait for download to complete on all nodes -gh es upgrade download status - -# Run pre-upgrade on all nodes at once (non-disruptive) -gh es upgrade apply --version VERSION --phase pre-upgrade - -# Wait for pre-upgrade to complete -gh es upgrade status --verbose - -# Enable maintenance mode -gh es maintenance set --enabled true - -# Upgrade the replica first (triggers reboot) -gh es upgrade apply --version VERSION --phase upgrade --uuid REPLICA-UUID -gh es upgrade status --uuid REPLICA-UUID --verbose - -# After the replica finishes, upgrade the primary -gh es upgrade apply --version VERSION --phase upgrade --uuid PRIMARY-UUID -gh es upgrade status --uuid PRIMARY-UUID --verbose - -# Verify replication health and version, then disable maintenance mode -gh es replication status -gh es release version -gh es maintenance set --enabled false -``` - -### Using the API - -```shell -# Download the package to all nodes -curl -L -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/download \ - -d '{"version":"VERSION"}' - -# Wait for download to complete on all nodes -curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/download/status - -# Run pre-upgrade on all nodes at once (non-disruptive) -curl -L -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/apply \ - -d '{"version":"VERSION","phase":"pre-upgrade"}' - -# Wait for pre-upgrade to complete -curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - "https://HOSTNAME:8443/manage/v1/upgrade/status?verbose=true" - -# Enable maintenance mode -curl -L -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/maintenance \ - -d '{"enabled":true}' - -# Upgrade the replica first (triggers reboot) -curl -L -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/apply \ - -d '{"version":"VERSION","phase":"upgrade","uuid":"REPLICA-UUID"}' - -# Monitor replica upgrade -curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - "https://HOSTNAME:8443/manage/v1/upgrade/status?uuid=REPLICA-UUID&verbose=true" - -# After the replica finishes, upgrade the primary -curl -L -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/upgrade/apply \ - -d '{"version":"VERSION","phase":"upgrade","uuid":"PRIMARY-UUID"}' - -# Monitor primary upgrade -curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - "https://HOSTNAME:8443/manage/v1/upgrade/status?uuid=PRIMARY-UUID&verbose=true" - -# Verify replication health and version, then disable maintenance mode -curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/replication/status - -curl -L \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/version - -curl -L -X POST \ - -u "api_key:ROOT-SITE-ADMINISTRATOR-PASSWORD" \ - -H "Content-Type: application/json" \ - https://HOSTNAME:8443/manage/v1/maintenance \ - -d '{"enabled":false}' -``` diff --git a/content/admin/upgrading-your-instance/automation-via-cli-api/index.md b/content/admin/upgrading-your-instance/automation-via-cli-api/index.md deleted file mode 100644 index e900ee1d4e72..000000000000 --- a/content/admin/upgrading-your-instance/automation-via-cli-api/index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Upgrade Automation With API or CLI -intro: 'You can automate appliance upgrade operation using the ghes-manage API and `es` plugin.' -versions: - ghes: '>= 3.21' -children: - - /enterprise-server-upgrade-automation ---- diff --git a/content/admin/upgrading-your-instance/index.md b/content/admin/upgrading-your-instance/index.md index ad0169a9d177..7d32e899c243 100644 --- a/content/admin/upgrading-your-instance/index.md +++ b/content/admin/upgrading-your-instance/index.md @@ -7,6 +7,8 @@ - /preparing-to-upgrade - /performing-an-upgrade - /troubleshooting-upgrades - - /automation-via-cli-api shortTitle: Upgrade your instance + redirect_from: + - /admin/upgrading-your-instance/automation-via-cli-api + - /admin/upgrading-your-instance/automation-via-cli-api/enterprise-server-upgrade-automation --- diff --git a/content/billing/concepts/billing-cycles.md b/content/billing/concepts/billing-cycles.md index dc782cf461c4..2562ebba43fa 100644 --- a/content/billing/concepts/billing-cycles.md +++ b/content/billing/concepts/billing-cycles.md @@ -37,10 +37,10 @@ For example, if you started a paid plan or converted from a trial on the 15th of ## Billing cycle for {% data variables.copilot.sandbox %} during public preview -During {% data variables.release-phases.public_preview %}, eligible accounts receive a **$10 monthly entitlement** for cloud sandbox usage in **June 2026**. The entitlement applies as follows: +During {% data variables.release-phases.public_preview %}, eligible accounts receive a **$10 monthly entitlement** for cloud sandbox usage through the end of **July 2026**. The entitlement applies as follows: * Usage above the entitlement is metered against your standard billing cycle and billed on your normal billing date. -* The entitlement is discontinued after June 2026. Pricing and packaging after the preview is subject to change. +* The entitlement is discontinued after July 2026. Pricing and packaging after the preview is subject to change. ## Billing cycles for volume-based products diff --git a/content/billing/concepts/product-billing/cloud-and-local-sandboxes.md b/content/billing/concepts/product-billing/cloud-and-local-sandboxes.md index 808e830cf366..c3ea3baecfa2 100644 --- a/content/billing/concepts/product-billing/cloud-and-local-sandboxes.md +++ b/content/billing/concepts/product-billing/cloud-and-local-sandboxes.md @@ -40,7 +40,7 @@ For more information about {% data variables.copilot.sandbox %}, see [AUTOTITLE] ## Free and billed use -During public preview, eligible {% data variables.product.github %} accounts receive a **$10 monthly entitlement** to try cloud sandboxes. This entitlement is available for June 2026. Any usage beyond the monthly entitlement is billed to your account. +During public preview, eligible {% data variables.product.github %} accounts receive a **$10 monthly entitlement** to try cloud sandboxes. This entitlement is available through the end of July 2026. Any usage beyond the monthly entitlement is billed to your account. After the preview period ends, the entitlement no longer applies and all usage is billed. diff --git a/content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md b/content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md index 6c78638ebeee..ad7a2d561e4b 100644 --- a/content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md +++ b/content/copilot/concepts/copilot-usage-metrics/copilot-metrics.md @@ -39,7 +39,7 @@ Metrics are available through: In addition, {% data variables.product.prodname_copilot_short %} usage metrics incorporate **server-side telemetry** to identify active users that client-side telemetry alone may miss. Network conditions, proxy configurations, and client settings can prevent client telemetry from reaching {% data variables.product.github %}, so server-side signals ensure those users still appear in your reports. -Users surfaced through server-side telemetry are fully counted toward your active user totals (such as daily active users), but their dimensional breakdowns—such as `totals_by_ide`, `totals_by_feature`, and lines-of-code metrics—remain empty until richer telemetry is available for them. Top-level totals and breakdowns for users already captured by client telemetry are unchanged. +Users surfaced through server-side telemetry are fully counted toward your active user totals (such as daily active users, `daily_active_users` ). When available, they may also appear in `totals_by_ide` (including the most recently detected IDE and {% data variables.product.prodname_copilot_short %} extension versions in per-user reports). However, other dimensional breakdowns—such as `totals_by_feature` and lines-of-code metrics—remain empty until richer telemetry is available for them. Top-level totals and breakdowns for users already captured by client telemetry are unchanged. The data **does not include** activity from other {% data variables.product.prodname_copilot_short %} surfaces, such as: diff --git a/content/copilot/reference/copilot-usage-metrics/reconciling-usage-metrics.md b/content/copilot/reference/copilot-usage-metrics/reconciling-usage-metrics.md index c906d10e20e6..463681d89343 100644 --- a/content/copilot/reference/copilot-usage-metrics/reconciling-usage-metrics.md +++ b/content/copilot/reference/copilot-usage-metrics/reconciling-usage-metrics.md @@ -81,6 +81,6 @@ The value `Unknown` appears in some API or export breakdowns when telemetry from ## Users surfaced by server-side telemetry -{% data variables.product.prodname_copilot_short %} usage metrics combine client-side and server-side telemetry to identify active users. Users confirmed as active through server-side telemetry, but for whom no client telemetry was received, are included in your active user totals (such as `daily_active_users`). However, their dimensional breakdowns (`totals_by_ide`, `totals_by_feature`, `totals_by_language_feature`, `totals_by_language_model`, `totals_by_model_feature`) and lines-of-code metrics will be empty. +{% data variables.product.prodname_copilot_short %} usage metrics combine client-side and server-side telemetry to identify active users. Users confirmed as active through server-side telemetry, but for whom no client telemetry was received, are included in your active user totals (such as `daily_active_users`). When available, these users may also appear in `totals_by_ide` (and in per-user reports this includes the most recently detected IDE and {% data variables.product.prodname_copilot_short %} extension versions). However, other dimensional breakdowns (`totals_by_feature`, `totals_by_language_feature`, `totals_by_language_model`, `totals_by_model_feature`) and lines-of-code metrics will still be empty. This means your top-level active user counts may be higher than the sum of users reflected in the breakdown arrays. This is expected behavior and does not indicate a data error.