diff --git a/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md b/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md index fb7fe38911b5..ae1b32a58079 100644 --- a/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md +++ b/content/admin/administering-your-instance/administering-your-instance-from-the-command-line/command-line-utilities.md @@ -1443,6 +1443,27 @@ To install an upgrade package: ghe-upgrade UPGRADE-PACKAGE-FILENAME ``` + +{% ifversion ghes > 3.20 %} + +Beginning with upgrades in version 3.21 operators may run many of the upgrade operations without requiring a maintenance window using phased execution. + +First run operations which do not require a maintenance window by triggering the pre-upgrade phase + +```shell +ghe-upgrade --phase pre-upgrade UPGRADE-PACKAGE-FILENAME +``` + +Once that is complete operators may complete the upgrade by running the final steps after a maintenance window has been scheduled + +```shell +ghe-upgrade --phase upgrade UPGRADE-PACKAGE-FILENAME +``` + +The upgraded {% data variables.product.prodname_enterprise %} host will be rebooted by this operation. + +{% endif %} + {% data reusables.enterprise_installation.command-line-utilities-ghe-upgrade-rollback %} ### ghe-upgrade-scheduler 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 new file mode 100644 index 000000000000..da562c0cb5e2 --- /dev/null +++ b/content/admin/upgrading-your-instance/automation-via-cli-api/enterprise-server-upgrade-automation.md @@ -0,0 +1,305 @@ +--- +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 new file mode 100644 index 000000000000..e900ee1d4e72 --- /dev/null +++ b/content/admin/upgrading-your-instance/automation-via-cli-api/index.md @@ -0,0 +1,8 @@ +--- +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 ad6b74bff376..ad0169a9d177 100644 --- a/content/admin/upgrading-your-instance/index.md +++ b/content/admin/upgrading-your-instance/index.md @@ -7,5 +7,6 @@ - /preparing-to-upgrade - /performing-an-upgrade - /troubleshooting-upgrades + - /automation-via-cli-api shortTitle: Upgrade your instance --- diff --git a/content/admin/upgrading-your-instance/performing-an-upgrade/upgrading-with-an-upgrade-package.md b/content/admin/upgrading-your-instance/performing-an-upgrade/upgrading-with-an-upgrade-package.md index 858d7c19f4e5..c15a4c5b145c 100644 --- a/content/admin/upgrading-your-instance/performing-an-upgrade/upgrading-with-an-upgrade-package.md +++ b/content/admin/upgrading-your-instance/performing-an-upgrade/upgrading-with-an-upgrade-package.md @@ -95,3 +95,26 @@ To upgrade a multi-node {% data variables.product.prodname_ghe_server %} environ {% data reusables.enterprise_installation.replication-status %} {% data reusables.enterprise_installation.replication-status-upgrade %} {% data reusables.enterprise_installation.multiple-node-repeat-upgrade-process %} {% data reusables.enterprise_installation.disable-maintenance-mode-after-replica-upgrade %} + +## Upgrading an instance using phased upgrade execution + +Phased upgrade execution allows {% data variables.product.prodname_ghe_server %} operators running versions 3.22 or greater better control over downtime-inducing actions by isolating those actions to their own phase. To use phased execution perform the following after downloading the upgrade package: +1. Run the package's pre-upgrade phase + + ```shell + ghe-upgrade --phase pre-upgrade GITHUB-UPGRADE.pkg + ``` + +1. Enable maintenance mode and wait for all active processes to complete on the {% data variables.product.prodname_ghe_server %} instance. See [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode). + + > [!NOTE] When upgrading the primary node in a high availability configuration, the instance should already be in maintenance mode if you are following the instructions in [Upgrading the primary node with an upgrade package](#upgrading-the-primary-node-with-an-upgrade-package). +1. Run the upgrade phase + + ```shell + ghe-upgrade --phase pre-upgrade GITHUB-UPGRADE.pkg + ``` + +1. Optionally, after the upgrade, validate the upgrade by configuring an IP exception list to allow access to a specified list of IP addresses. See [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list). +1. For single node upgrades, perform any post-upgrade tasks including disabling maintenance mode so users can use {% data variables.location.product_location %}. + + > [!NOTE] After you upgrade an instance in a high availability configuration, you should remain in maintenance mode until you have upgraded all of the replica nodes and replication is current. See [Upgrading additional nodes with an upgrade package](#upgrading-additional-nodes-with-an-upgrade-package). diff --git a/content/billing/concepts/budgets-and-alerts.md b/content/billing/concepts/budgets-and-alerts.md index 5406c9a38bf8..69bf45c8c224 100644 --- a/content/billing/concepts/budgets-and-alerts.md +++ b/content/billing/concepts/budgets-and-alerts.md @@ -24,7 +24,12 @@ For metered products such as {% data variables.product.prodname_actions %}, {% d Each budget has a type and a scope that define which paid use contributes to spending against the budget. * **Type**: Defines which metered product or SKU is measured. -* **Scope**: Defines whether the budget applies to the whole account, or to a subset of repositories, organizations, cost centers (enterprise only), or users. User-scoped budgets are currently only supported for {% data variables.product.prodname_copilot_short %} {% data variables.product.prodname_ai_credits_short %}. There are two types: a universal budget that applies to all licensed users by default, and individual budgets that override the universal for specific users. See [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing). +* **Scope**: Defines whether the budget applies to the whole account, or to a subset of repositories, organizations, cost centers (enterprise only), or users. User-scoped budgets are currently only supported for {% data variables.product.prodname_copilot_short %} {% data variables.product.prodname_ai_credits_short %}, and have three scopes: + * **Universal**: applies to all licensed users by default + * **Cost center user-level**: applies to every user in a cost center + * **Individual**: overrides the above for specific users + +For more information about how user-level budgets work and how they interact with other budget controls, see [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing). ## Budget alerts diff --git a/content/billing/how-tos/set-up-budgets.md b/content/billing/how-tos/set-up-budgets.md index 650fe963f652..86ea0854df4f 100644 --- a/content/billing/how-tos/set-up-budgets.md +++ b/content/billing/how-tos/set-up-budgets.md @@ -117,7 +117,8 @@ As the owner of an enterprise or organization account, or as a billing manager, * **Cost center**: Tracks spending for a single cost center. * **Users**: Sets a per-user budget. Available when you select **Bundled {% data variables.product.prodname_ai_credits_short %} budget** as the budget type. * Leave the user field empty to create a universal budget that applies to all {% data variables.product.prodname_copilot_short %}-licensed users. - * Select a specific user to create an individual budget that overrides the universal default for that user. + * Select a cost center to create a user-level budget that applies to every user in that cost center. This sets one per-user amount for all current and future members, and overrides the universal budget for them. + * Select a specific user to create an individual budget that overrides both the universal budget and any cost center user-level budget for that user. 1. Under "Budget", set a budget amount or license count. diff --git a/content/billing/tutorials/control-costs-at-scale.md b/content/billing/tutorials/control-costs-at-scale.md index 1416a88fad2c..14d08085307d 100644 --- a/content/billing/tutorials/control-costs-at-scale.md +++ b/content/billing/tutorials/control-costs-at-scale.md @@ -21,6 +21,7 @@ This tutorial guides you through planning, creating, and managing cost centers u As your enterprise grows, you can layer increasingly granular controls on top of cost centers to keep {% data variables.product.prodname_copilot_short %} spending predictable: * **Group at scale.** Assign whole enterprise teams to a cost center so membership stays current automatically as people join and leave. +* **Cap per-user spending.** Set a cost center user-level budget so every member of a cost center inherits the same per-person limit. See [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing). ## 1. Plan your cost center strategy @@ -316,4 +317,5 @@ If there are any paid products that you want to block all access to, you can dis To go deeper on the controls in this tutorial: +* For how cost center budgets and user-level budgets interact across the pool and metered phases, see [AUTOTITLE](/copilot/concepts/billing/budgets-for-usage-based-billing). * For how resources are allocated to cost centers, including enterprise team membership, see [AUTOTITLE](/billing/reference/cost-center-allocation). diff --git a/content/code-security/concepts/supply-chain-security/open-source-license-compliance.md b/content/code-security/concepts/supply-chain-security/open-source-license-compliance.md index 529ec1d76150..97c747dbe6f1 100644 --- a/content/code-security/concepts/supply-chain-security/open-source-license-compliance.md +++ b/content/code-security/concepts/supply-chain-security/open-source-license-compliance.md @@ -1,6 +1,6 @@ --- title: About open source license compliance -shortTitle: Open Source license compliance +shortTitle: Open source license compliance intro: Define and enforce license policy for dependencies in your repositories with open source license compliance. product: 'Organizations owned by an enterprise account with {% data variables.product.prodname_GH_code_security %} enabled' versions: @@ -18,11 +18,11 @@ Open source license compliance helps you **track dependency licenses** and **enf ## How license policy works -You can define an enterprise or organization policy that controls which licenses dependencies are allowed to use. +You can define an enterprise policy that controls which licenses your dependencies are allowed to use. You can specify licenses from either a built-in list or, if a license is not listed, by manually adding a SPDX license identifier. -Your policy is applied at the enterprise, organization, and repository scope. You can also add package or license exceptions when an **Enterprise Open Source License Manager** approves requests. +Your policy is enforced by rulesets that can be defined at the enterprise, organization, and repository scope. You can also add package or license exceptions when an **Enterprise Open Source License Manager** approves requests. License evaluation uses dependency data from your repositories, including transitive dependencies detected in the dependency graph. diff --git a/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries.md b/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries.md index f5ba4d7dbf6e..4303b2a4c737 100644 --- a/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries.md +++ b/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries.md @@ -559,6 +559,34 @@ registries: For security reasons, {% data variables.product.prodname_dependabot %} does not set environment variables. Yarn (v2 and later) requires that any accessed environment variables are set. When accessing environment variables in your `.yarnrc.yml` file, you should provide a fallback value such as {% raw %}`${ENV_VAR-fallback}`{% endraw %} or {% raw %}`${ENV_VAR:-fallback}`{% endraw %}. For more information, see [Yarnrc files](https://yarnpkg.com/configuration/yarnrc) in the Yarn documentation. +{% ifversion dependabot-npm-scope %} + +#### Using `scope` to map npm scopes to registries + +You can use the `scope` parameter to associate an npm scope with a private registry. When `scope` is configured, {% data variables.product.prodname_dependabot %} generates the `.npmrc` from your registry credentials, which takes precedence over any committed `.npmrc` file or lockfile-based inference. The scope value must start with `@`, for example `@my-company`. To associate multiple scopes with the same registry, create a separate registry entry for each scope. + +In the following example, packages under `@my-company` and `@my-other-org` are both routed to the private {% data variables.product.github %} npm registry, each with its own registry entry. + +{% raw %} + +```yaml copy +registries: + npm-github-company: + type: npm-registry + url: https://npm.pkg.github.com + scope: "@my-company" + token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}} + npm-github-other-org: + type: npm-registry + url: https://npm.pkg.github.com + scope: "@my-other-org" + token: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}} +``` + +{% endraw %} + +{% endif %} + ### `nuget-feed` The `nuget-feed` type supports username and password, or token. {% data reusables.dependabot.password-definition %} diff --git a/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-license-policies.md b/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-license-policies.md index cad9a66f6e40..31ac071a5ffb 100644 --- a/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-license-policies.md +++ b/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-license-policies.md @@ -19,7 +19,7 @@ redirect_from: Before you configure license policies, ensure that: * Your organization has {% data variables.product.prodname_GH_code_security %} -* You have access to manage enterprise or organization policy and rulesets +* You have access to manage enterprise policy and rulesets * Dependency graph is enabled for repositories you want to evaluate ## About license compliance @@ -31,7 +31,7 @@ When the policy is enforced with rulesets, {% data variables.product.github %} e Violations are typically resolved by: * Updating the pull request to use compliant dependencies -* Approving an exception for a package or license +* Approving an exception for a package * Updating policy to allow a license where appropriate ## Create a license policy @@ -66,7 +66,7 @@ Assigning this role also subscribes reviewers to request notifications so they c ## Optionally use custom properties to control rollout per repository -If you want gradual rollout, use a repository custom property to control whether each repository is in inactive, evaluate, or active enforcement mode. +If you want a gradual rollout, use a repository custom property to control whether each repository is in inactive, evaluate, or active enforcement mode. {% data reusables.organizations.navigate-to-org %} {% data reusables.organizations.org_settings %} @@ -126,4 +126,4 @@ After a request is approved, the alert is closed and the pull request is unblock ## Further reading -* [AUTOTITLE](/code-security/concepts/supply-chain-security/open-source-license-compliance). \ No newline at end of file +* [AUTOTITLE](/code-security/concepts/supply-chain-security/open-source-license-compliance) diff --git a/content/code-security/reference/supply-chain-security/dependabot-options-reference.md b/content/code-security/reference/supply-chain-security/dependabot-options-reference.md index 0a80784755ac..0cae870bec80 100644 --- a/content/code-security/reference/supply-chain-security/dependabot-options-reference.md +++ b/content/code-security/reference/supply-chain-security/dependabot-options-reference.md @@ -1037,3 +1037,22 @@ For more information about OIDC support for {% data variables.product.prodname_ ### `url` and `replaces-base` The `url` parameter defines where to access a registry. When the optional `replaces-base` parameter is enabled (`true`), {% data variables.product.prodname_dependabot %} resolves dependencies using the value of `url` rather than the base URL of that specific ecosystem. + +{% ifversion dependabot-npm-scope %} + +### `scope` + +The `scope` parameter is available for `npm-registry` type registries. It specifies which npm scope should be associated with the registry. The value must start with `@`, for example `@my-company`. To associate multiple scopes with the same registry URL, create a separate registry entry for each scope. + +When `scope` is provided, {% data variables.product.prodname_dependabot %} generates the `.npmrc` configuration from your registry credentials. This generated configuration takes precedence over any committed `.npmrc` file or lockfile-based inference. + +#### Priority order for npm registry resolution + +When determining which registry to use for npm dependencies, {% data variables.product.prodname_dependabot %} follows this priority order: + +1. **Credential-based generation (`scope` or `replaces-base`):** If `scope` or `replaces-base` is configured on any `npm-registry` credential in `dependabot.yml`, {% data variables.product.prodname_dependabot %} generates the `.npmrc` from those credentials. This always takes priority, overriding any committed `.npmrc` file. +1. **Committed `.npmrc` in the repository:** If no `scope` is set, {% data variables.product.prodname_dependabot %} uses any `.npmrc` file committed to the repository. +1. **Lockfile inference (transitional):** If there is no `scope` and no committed `.npmrc`, {% data variables.product.prodname_dependabot %} attempts to infer registry configuration from the lockfile. +1. **Error generation:** If none of the above methods succeed, {% data variables.product.prodname_dependabot %} reports an error with guidance to add explicit configuration. + +{% endif %} diff --git a/content/copilot/concepts/billing/budgets-for-usage-based-billing.md b/content/copilot/concepts/billing/budgets-for-usage-based-billing.md index 7919a32f0b5e..d9679b8962f7 100644 --- a/content/copilot/concepts/billing/budgets-for-usage-based-billing.md +++ b/content/copilot/concepts/billing/budgets-for-usage-based-billing.md @@ -11,7 +11,7 @@ category: - Manage Copilot for a team --- -Every {% data variables.product.prodname_copilot_short %} license includes {% data variables.product.prodname_ai_credits_short %} that are pooled across your enterprise. Budget controls let you govern how individual users draw from that pool, and cap any additional spending once it's exhausted. This article explains what each budget control does, how the system evaluates them, and what happens when a limit is reached. +Every {% data variables.product.prodname_copilot_short %} license includes {% data variables.product.prodname_ai_credits_short %} that are pooled across your enterprise. Budget controls let you govern how individual users draw from that pool and cap any additional spending once the pool is exhausted. This article explains what each control does, how the system evaluates them, and what happens when a limit is reached. ## Understanding budget controls @@ -21,10 +21,13 @@ You have budget controls at the user, organization, cost center, and enterprise The user-level budget (ULB) caps how many {% data variables.product.prodname_ai_credits_short %} a single user can consume in a billing cycle—both from the shared pool and from additional (metered) usage. This is the only control that is active during both the pool phase and the metered phase. ULBs always enforce a hard stop; there is no option to allow usage to continue beyond the limit. A $0 USD budget blocks the user immediately. -There are two types: +There are three types, listed from the broadest scope to the most specific: * **Universal user-level budget:** A default budget applied to every {% data variables.product.prodname_copilot_short %}-licensed user in your enterprise. This is your primary tool for ensuring fair access to the shared pool. -* **Individual user-level budget:** A budget set for a specific user, which overrides the universal default and takes precedence over it entirely. Use this for power users who need higher limits, or to restrict specific users to a lower amount. +* **Cost center user-level budget:** A default budget applied to every user in a single cost center, sometimes called a group-scoped user-level budget. You set one per-user amount on the cost center and it applies to every current and future member, so you can give different departments different per-user limits—for example, $20 USD per user for engineering and $5 USD per user for marketing—without creating thousands of individual budgets. It overrides the universal budget for members of that cost center. +* **Individual user-level budget:** A budget set for a specific user, which overrides both the universal default and any cost center user-level budget. Use this for power users who need higher limits, or to restrict specific users to a lower amount. + +When more than one type applies to a user, the most specific budget wins: an individual user-level budget takes precedence over a cost center user-level budget, which takes precedence over the universal user-level budget. #### When users appear in a universal user-level budget @@ -36,8 +39,13 @@ For a complete view of all licensed users regardless of activity, use the **AI u A cost center budget caps metered charges for a defined group of users or an organization. It does not limit how much a team draws from the pool. It is only active after the shared pool is exhausted. A cost center budget **does not extend or override a user-level budget**: if a user has reached their user-level budget, they are blocked even if their cost center still has remaining budget. +Members of a cost center can be assigned directly, through an organization, or through an enterprise team. For how usage is allocated when more than one assignment applies to a user, see [AUTOTITLE](/billing/reference/cost-center-allocation). + When a cost center's budget is exhausted, only users in that cost center are blocked. Other users and cost centers are unaffected. +> [!NOTE] +> A cost center budget is different from a cost center user-level budget. A cost center budget caps the team's **total metered charges** after the pool is exhausted. A cost center user-level budget caps **each member's individual consumption** across both the pool and metered phases, the same way other user-level budgets do. You can apply both to the same cost center. + ### Organization budget An organization budget caps metered charges for users who receive their {% data variables.product.prodname_copilot_short %} license through that organization. Like cost center budgets, it is only active after the shared pool is exhausted. @@ -58,7 +66,8 @@ The enterprise budget caps total metered charges across your entire enterprise. | Control | What it caps | When it's active | Scope | Hard stop? | | --- | --- | --- | --- | --- | | Universal user-level budget | Each user's total {% data variables.product.prodname_ai_credit_singular %} consumption | Always (pool + metered) | Per user | Always | -| Individual user-level budget | A specific user's total consumption (overrides universal) | Always (pool + metered) | Per user | Always | +| Cost center user-level budget | Each member's total consumption, set per cost center (overrides universal) | Always (pool + metered) | Per user, by cost center | Always | +| Individual user-level budget | A specific user's total consumption (overrides universal and cost center user-level budgets) | Always (pool + metered) | Per user | Always | | Cost center budget | A team's metered charges after pool exhaustion | Metered phase only | Per cost center | Only if "Stop usage when budget limit is reached" is enabled | | Organization budget | An organization's metered charges after pool exhaustion | Metered phase only | Per organization | Only if "Stop usage when budget limit is reached" is enabled | | Enterprise budget | Total enterprise metered charges after pool exhaustion | Metered phase only | Enterprise-wide | Only if "Stop usage when budget limit is reached" is enabled | @@ -74,7 +83,7 @@ When someone in your enterprise uses {% data variables.product.prodname_copilot_ Each request for an {% data variables.product.prodname_ai_credit_singular %}-consuming feature goes through these checks: -1. **User-level budget check.** The system first checks whether the user has exceeded their user-level budget. If yes, the request is blocked immediately. ULBs are always a hard stop, and no other budget can override or supplement them. If no (or no ULB is set), the request continues. +1. **User-level budget check.** The system first checks whether the user has exceeded their user-level budget. When a user has more than one type of user-level budget, the most specific one applies: an individual budget if set, otherwise the budget for the user's cost center, otherwise the universal budget. If the applicable budget is exceeded, the request is blocked immediately. ULBs are always a hard stop, and no other budget can override or supplement them. If no user-level budget is set, the request continues. 1. **Shared pool check.** Next, the system checks whether the shared pool has {% data variables.product.prodname_ai_credits_short %} remaining. If yes, the request is served from the pool at no extra cost. If the pool is empty, the request moves to metered usage at {% data variables.product.prodname_ai_credits_value %} per {% data variables.product.prodname_ai_credit_singular %}. 1. **Cost center, organization, or enterprise check.** For metered usage, the system checks budgets in the following order: diff --git a/content/copilot/tutorials/budgets/optimizing-your-budget-configuration.md b/content/copilot/tutorials/budgets/optimizing-your-budget-configuration.md index bd807048094f..68a3024cad17 100644 --- a/content/copilot/tutorials/budgets/optimizing-your-budget-configuration.md +++ b/content/copilot/tutorials/budgets/optimizing-your-budget-configuration.md @@ -28,7 +28,7 @@ The relationship between user-level budgets (ULB) and other budgets is the most Here's how to estimate: -1. Calculate the maximum total consumption your user-level budgets allow: multiply the number of regular users by the universal ULB, then add the sum of any individual ULB overrides. +1. Calculate the maximum total consumption your user-level budgets allow. For users on the universal budget, multiply their number by the universal ULB. Add the total for any cost center user-level budgets—the per-user amount multiplied by the number of users in each cost center. Then add the sum of any individual ULB overrides. 1. Calculate your pool value: multiply your {% data variables.copilot.copilot_business_short %} seats by {% data variables.copilot.cfb_price_per_month %} and your {% data variables.copilot.copilot_enterprise_short %} seats by {% data variables.copilot.ce_price_per_month %}, then add them together. 1. Subtract the pool value from the maximum total consumption. The result is the maximum metered charges your budgets need to cover. @@ -89,6 +89,20 @@ With this configuration, each business unit has its own metered spending cap. Wh Consider enabling **cost center exclusion** if you want business units to operate independently of the enterprise budget. This allows cost center users to keep spending even if the enterprise budget reaches $0 USD, but it means their metered charges are only capped by their own cost center budget. +### Differentiate per-user limits by team + +**Situation:** Different departments need different per-user limits, for example, engineering needs more capacity per developer than marketing, but you don't want to manage thousands of individual budgets. + +**Configuration:** + +* Create **cost centers** for each department and assign users directly. See [AUTOTITLE](/billing/how-tos/products/use-cost-centers). +* Set a **cost center user-level budget** for each department to give every member of that cost center the same per-user limit. +* Set **individual user-level budget overrides** for any specific users who need a different limit than their department's default. +* Set an **enterprise budget** as a failsafe for metered charges. +* Enable **"Stop usage when budget limit is reached"** on the enterprise budget. + +A cost center user-level budget sets one per-user amount that applies to every current and future member of the cost center, so you can adjust a department's limit in one place instead of editing budgets user by user. Precedence runs from most specific to least specific: an individual budget overrides a cost center user-level budget, which overrides the universal budget. + ### Power users within business units **Situation:** You want per-team accountability and need to give specific developers higher limits within a business unit. diff --git a/content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/disabling-issues.md b/content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/disabling-issues.md index 4a24818b5f42..37799f421376 100644 --- a/content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/disabling-issues.md +++ b/content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/disabling-issues.md @@ -19,6 +19,16 @@ category: If you decide to enable issues again in the future, any issues that were previously added will be available. +{% ifversion disable-restrict-issues %} + +1. To restrict issues to collaborators only, in the dropdown under "Issues" select **Collaborators only**. + + In personal repositories, a collaborator is anyone who has been invited to the repository. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/repository-access-and-collaboration/permission-levels-for-a-personal-account-repository#collaborator-access-for-a-repository-owned-by-a-personal-account). + + In organization repositories, a collaborator is a user who has been granted the write, maintain, or admin role for the repository. For more information about organization roles, see [AUTOTITLE](/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization#repository-roles-for-organizations). + +{% endif %} + {% ifversion fpt or ghec %} > [!TIP] diff --git a/data/features/dependabot-npm-scope.yml b/data/features/dependabot-npm-scope.yml new file mode 100644 index 000000000000..fc25343c2a80 --- /dev/null +++ b/data/features/dependabot-npm-scope.yml @@ -0,0 +1,7 @@ +# Reference: #22071 +# Dependabot will stop inferring .npmrc [GA] +# Add `scope` field to npm-registry credentials for explicit .npmrc generation [GA] +versions: + fpt: '*' + ghec: '*' + ghes: '>3.22' diff --git a/data/features/disable-restrict-issues.yml b/data/features/disable-restrict-issues.yml new file mode 100644 index 000000000000..6c7984c8bf6b --- /dev/null +++ b/data/features/disable-restrict-issues.yml @@ -0,0 +1,6 @@ +# Reference: TODO: add internal tracking issue number for restricting issues to collaborators +# Disable/restrict issues for a repository +versions: + fpt: '*' + ghec: '*' + ghes: '>= 3.21' diff --git a/data/reusables/billing/enterprise-teams-in-cost-centers.md b/data/reusables/billing/enterprise-teams-in-cost-centers.md index 20cd17d5ff8c..7ccad872a006 100644 --- a/data/reusables/billing/enterprise-teams-in-cost-centers.md +++ b/data/reusables/billing/enterprise-teams-in-cost-centers.md @@ -1 +1 @@ -You can assign an enterprise team to a cost center. Every member of the team is added to the cost center, and membership stays current automatically as people join or leave the team, so you don't have to add or remove users one by one. For more information about enterprise teams, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams). +You can assign an enterprise team to a cost center. Every member of the team is added to the cost center, and membership stays current automatically as people join or leave the team—so you don't have to add or remove users one by one. For more information about enterprise teams, see [AUTOTITLE](/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams). diff --git a/data/reusables/dependabot/dependabot-updates-registries-options.md b/data/reusables/dependabot/dependabot-updates-registries-options.md index d6461390a2d6..ab4710cfda17 100644 --- a/data/reusables/dependabot/dependabot-updates-registries-options.md +++ b/data/reusables/dependabot/dependabot-updates-registries-options.md @@ -7,3 +7,6 @@ You use the following options to specify access settings. Registry settings must | Authentication details | **Required:** The parameters supported for supplying authentication details vary for registries of different types. | | `url` | **Required:** The URL to use to access the dependencies in this registry. The protocol is optional. If not specified, `https://` is assumed. {% data variables.product.prodname_dependabot %} adds or ignores trailing slashes as required. | | `replaces-base` | If the boolean value is `true`, {% data variables.product.prodname_dependabot %} resolves dependencies using the specified `url` rather than the base URL of that ecosystem. | +| {% ifversion dependabot-npm-scope %} | +| `scope` | For `npm-registry` type only. The npm scope to associate with this registry, for example `@my-company`. When `scope` is provided, {% data variables.product.prodname_dependabot %} generates the `.npmrc` configuration from the registry credentials, overriding any committed `.npmrc` file or lockfile inference. | +| {% endif %} |