diff --git a/content/apps/creating-github-apps/registering-a-github-app/using-webhooks-with-github-apps.md b/content/apps/creating-github-apps/registering-a-github-app/using-webhooks-with-github-apps.md index e951525fcca5..ce2c3b67395c 100644 --- a/content/apps/creating-github-apps/registering-a-github-app/using-webhooks-with-github-apps.md +++ b/content/apps/creating-github-apps/registering-a-github-app/using-webhooks-with-github-apps.md @@ -33,7 +33,7 @@ When you activate webhooks for your {% data variables.product.prodname_github_ap ### Choosing a webhook URL for development and testing -While you develop and test your app, you can use a webhook payload delivery service like [Smee](https://smee.io/) to capture and forward webhook payloads to your local development environment. Never use Smee for an application in production, because Smee channels are not authenticated or secure. Alternatively, you can use a tool like [ngrok](https://ngrok.com/docs/getting-started/), [localtunnel](https://localtunnel.github.io/www/), or the [Hookdeck Console](https://console.hookdeck.com?provider=github) that exposes your local machine to the internet to receive the payloads. +While you develop and test your app, you can use a webhook payload delivery service like [Smee](https://smee.io/) to capture and forward webhook payloads to your local development environment. Never use Smee for an application in production, because Smee channels are not authenticated or secure. Alternatively, you can use a tool like [ngrok](https://ngrok.com/docs/getting-started/), [localtunnel](https://localtunnel.github.io/www/), or the [Hookdeck CLI](https://hookdeck.com/docs/cli) that exposes your local machine to the internet to receive the payloads. To view payloads in your browser without running a server, use [Hookdeck Inspect](https://inspect.hookdeck.com/webhooks/github). #### Creating a webhook URL with Smee @@ -47,7 +47,7 @@ You can use Smee to create a unique domain where {% data variables.product.prodn For an application in production that receives a low volume of webhook traffic, you can host it on any dynamic application server. The server-side code for handling the webhook can receive the event, deserialize its JSON payload, and decide what action to take, such as storing the data in a database or calling the {% data variables.product.prodname_dotcom %} API. -To handle a higher volume of webhook traffic for a large app in production, consider using asynchronous webhook handling on a dedicated server. You can achieve this by employing a queue, where the webhook handler pushes data to the queue, and separate processes perform subsequent actions based on the events. Additionally, you can use cloud functions such as [Azure Functions](https://azure.microsoft.com/en-us/products/functions/), [AWS Lambda](https://aws.amazon.com/lambda/), or [Hookdeck](https://hookdeck.com) to help scale the app for handling large volumes of webhook events. +To handle a higher volume of webhook traffic for a large app in production, consider using asynchronous webhook handling on a dedicated server. You can achieve this by employing a queue, where the webhook handler pushes data to the queue, and separate processes perform subsequent actions based on the events. Additionally, you can use cloud functions such as [Azure Functions](https://azure.microsoft.com/en-us/products/functions/), [AWS Lambda](https://aws.amazon.com/lambda/), or a webhook queuing service like [Hookdeck Event Gateway](https://hookdeck.com/event-gateway), to help scale the app for handling large volumes of webhook events. ## Securing your webhooks with a webhook secret diff --git a/content/contributing/writing-for-github-docs/creating-reusable-content.md b/content/contributing/writing-for-github-docs/creating-reusable-content.md index 4f8424015ffc..bdd2c371dbbf 100644 --- a/content/contributing/writing-for-github-docs/creating-reusable-content.md +++ b/content/contributing/writing-for-github-docs/creating-reusable-content.md @@ -30,7 +30,7 @@ Reusables can include Liquid conditionals to conditionally render content depend Variables are short strings of reusable text. -We use YAML files for variables. +We use YAML files for variables. Define each variable as a string value with a top-level key. You can organize the files in subdirectories. The path, filename, and keys within each YAML file determine what its path will be in the data object. @@ -38,12 +38,8 @@ For example, this YAML file, `{% raw %}data/variables/foo/bar.yml{% endraw %}`, ```yaml # the YAML file can contain multiple short strings in one file -meaning_of_life: 42 - -# the strings can also be nested if needed -nested: - values: - too: Yes! +meaning_of_life: '42' +affirmation: 'Yes!' ``` -The values would be accessible as `{% raw %}{% data foo.bar.meaning_of_life %}{% endraw %}` and `{% raw %}{% data foo.bar.nested.values.too %}{% endraw %}`. +The values would be accessible as `{% raw %}{% data variables.foo.bar.meaning_of_life %}{% endraw %}` and `{% raw %}{% data variables.foo.bar.affirmation %}{% endraw %}`. diff --git a/content/copilot/how-tos/troubleshoot-copilot/troubleshoot-network-errors.md b/content/copilot/how-tos/troubleshoot-copilot/troubleshoot-network-errors.md index 80db07eda840..3540cbbae049 100644 --- a/content/copilot/how-tos/troubleshoot-copilot/troubleshoot-network-errors.md +++ b/content/copilot/how-tos/troubleshoot-copilot/troubleshoot-network-errors.md @@ -42,6 +42,17 @@ If you're specifically having difficulty with {% data variables.copilot.copilot_ If you're unable to connect and the `curl` requests don't help to identify the error, it may help to collect detailed diagnostic logs in your editor. If you're working with your company's IT department or {% data variables.contact.contact_support_page %}, sharing these diagnostics may help to resolve the error. Enabling debug logging in your editor will help you to share more specific information. For more information, see [AUTOTITLE](/copilot/how-tos/troubleshoot-copilot/view-logs). +## Troubleshooting cloud-session WebSocket connections + +Cloud sessions in your browser use secure WebSocket connections to Azure Web PubSub. If a session fails to connect or stops showing updates, a firewall, proxy, VPN, or security tool may be blocking or interrupting that connection. A successful HTTPS request to a {% data variables.product.github %} endpoint doesn't test this separate connection. + +1. Open your browser's developer tools and use the network panel to inspect WebSocket requests while starting the affected session. Look for a request to a hostname ending in `.webpubsub.azure.com`. Record the hostname, the time of the failure, and any error message. Don't share the full connection URL, which can contain an access token. Before sharing error messages, screenshots, or network logs, remove access tokens, cookies, and URL query strings. +1. Ask your network administrator to confirm that the required hostname is allowed, and that your proxy or firewall supports secure WebSocket traffic on TCP port 443 and ongoing messages in both directions. See [AUTOTITLE](/copilot/reference/copilot-allowlist-reference#websocket-connections-for-cloud-sessions). +1. If your network uses TLS inspection, ask your network security team to check whether inspection is interfering with the connection. If they confirm interference, any inspection exception must follow your organization's security policy and be limited to the required hosts. Don't disable certificate validation. +1. Retry the affected session and confirm that it connects and receives updates, because an HTTP `101 Switching Protocols` response only confirms the WebSocket upgrade. + +If the problem continues, contact {% data variables.contact.github_support %} with the session URL, the time of the failure, the WebSocket hostname, and any error messages. A network configuration change won't resolve every session-startup failure. + ## Troubleshooting proxy errors If there is a problem with your proxy setup, you may see the following error: `{% data variables.product.prodname_copilot %} could not connect to server. Extension activation failed: "read ETIMEDOUT" or "read ECONNRESET"`. This error can be caused by a range of network issues. diff --git a/content/copilot/how-tos/use-copilot-agents/use-code-review.md b/content/copilot/how-tos/use-copilot-agents/use-code-review.md index 3cd3669768f1..d472ef56ecb1 100644 --- a/content/copilot/how-tos/use-copilot-agents/use-code-review.md +++ b/content/copilot/how-tos/use-copilot-agents/use-code-review.md @@ -147,7 +147,7 @@ To provide feedback on a review comment from {% data variables.product.prodname_ You can request an initial review of a highlighted selection of code in {% data variables.product.prodname_vscode %}. 1. In {% data variables.product.prodname_vscode %}, select the code you want to review. -1. Right-click the selected code and choose **Generate Code** > **Review**. +1. Right-click the selected code and choose **Review**. 1. {% data variables.product.prodname_vscode_shortname %} creates review comments in the **Comments** panel and also shows them inline in the editor. ### Reviewing all uncommitted changes diff --git a/content/copilot/reference/copilot-allowlist-reference.md b/content/copilot/reference/copilot-allowlist-reference.md index 01a0955d900e..c81b1ff2acd4 100644 --- a/content/copilot/reference/copilot-allowlist-reference.md +++ b/content/copilot/reference/copilot-allowlist-reference.md @@ -55,6 +55,13 @@ The following table lists specific domains required for {% data variables.produc | `https://copilot-reports.github.com` | {% data variables.product.prodname_copilot_short %} usage metrics report downloads | `*.github.com` | | `https://copilot-reports-*.b01.azurefd.net` | {% data variables.product.prodname_copilot_short %} usage metrics report downloads (fallback). Required for fallback scenarios where downloads bypass the custom domain and are served from an Azure Front Door CDN. | Not included | | `https://usagereports*.blob.core.windows.net` | {% data variables.product.prodname_copilot_short %} usage metrics report downloads (fallback). Required for fallback scenarios where downloads bypass the Azure Front Door CDN and are served directly from Azure Blob Storage. | Not included | +| `wss://production-copilot-host-centralus.webpubsub.azure.com` | Real-time WebSocket connection used by {% data variables.product.prodname_copilot_short %} on {% data variables.product.github %} to stream events and updates. Allow secure WebSocket traffic over TCP port 443. | Not included | +| `wss://production-copilot-host-centralus-02.webpubsub.azure.com` | Real-time WebSocket connection used by {% data variables.product.prodname_copilot_short %} on {% data variables.product.github %} to stream events and updates. Allow secure WebSocket traffic over TCP port 443. | Not included | +| `wss://production-copilot-host-eastasia.webpubsub.azure.com` | Real-time WebSocket connection used by {% data variables.product.prodname_copilot_short %} on {% data variables.product.github %} to stream events and updates. Allow secure WebSocket traffic over TCP port 443. | Not included | +| `wss://production-copilot-host-austriaeast.webpubsub.azure.com` | Real-time WebSocket connection used by {% data variables.product.prodname_copilot_short %} on {% data variables.product.github %} to stream events and updates. Allow secure WebSocket traffic over TCP port 443. | Not included | +| `wss://production-copilot-host-westus.webpubsub.azure.com` | Real-time WebSocket connection used by {% data variables.product.prodname_copilot_short %} on {% data variables.product.github %} to stream events and updates. Allow secure WebSocket traffic over TCP port 443. | Not included | +| `wss://production-copilot-host-westus3.webpubsub.azure.com` | Real-time WebSocket connection used by {% data variables.product.prodname_copilot_short %} on {% data variables.product.github %} to stream events and updates. Allow secure WebSocket traffic over TCP port 443. | Not included | +| `wss://production-copilot-host.webpubsub.azure.com` | Real-time WebSocket connection used by {% data variables.product.prodname_copilot_short %} on {% data variables.product.github %} to stream events and updates. Allow secure WebSocket traffic over TCP port 443. | Not included | ## {% data variables.product.prodname_copilot_short %} on {% data variables.enterprise.data_residency_site %} @@ -69,12 +76,22 @@ If you use {% data variables.enterprise.data_residency %}, your enterprise and { 1. If you plan to use public code detection, allow access to `https://origin-tracker.githubusercontent.com`. This is required to check generated code against public code hosted on {% data variables.product.prodname_dotcom_the_website %}. For more information, see [AUTOTITLE](/copilot/concepts/copilot-surfaces/copilot-in-ides#references-to-matching-public-code). +1. For cloud sessions in your browser, also allow the Azure Web PubSub hostname used by your enterprise. Find the exact hostname ending in `.webpubsub.azure.com` in the WebSocket request in your browser's developer tools while starting a session, or contact {% data variables.contact.github_support %} to confirm it. Allow secure WebSocket traffic over TCP port 443 to that hostname. + All other domains that are required on {% data variables.product.prodname_dotcom_the_website %} are **not** required on {% data variables.enterprise.data_residency_site %}. For example: * Individual services have a dedicated endpoint on your subdomain (such as `https://copilot-proxy.SUBDOMAIN.ghe.com/`) * Client experimentation is disabled on {% data variables.enterprise.data_residency_site %}, so `https://default.exp-tas.com` is not required * Individual {% data variables.product.prodname_copilot_short %} plans are not available on {% data variables.enterprise.data_residency_site %}, so subscription-based network routing (such as `https://*.individual.githubcopilot.com`) is not supported +## WebSocket connections for cloud sessions + +Cloud sessions in your browser use secure WebSocket connections to Azure Web PubSub to send and receive session events. In addition to allowing the applicable hostnames above, your proxy or firewall must support the WebSocket connection and ongoing messages in both directions. Allowing ordinary HTTPS requests alone doesn't confirm that WebSocket connections will work. + +Apply these rules to the network path between your browser and the service, including any proxy, VPN, or security software. These rules are separate from the firewall inside a {% data variables.product.prodname_copilot_short %} cloud environment. + +Use the required hostnames rather than allowing every Azure Web PubSub service with `*.webpubsub.azure.com`. For help diagnosing failed connections or interference from TLS inspection, see [AUTOTITLE](/copilot/how-tos/troubleshoot-copilot/troubleshoot-network-errors#troubleshooting-cloud-session-websocket-connections). + ## Editor-specific requirements In addition to the URLs required to connect to {% data variables.product.prodname_copilot_short %}, you must ensure your network rules meet the requirements of the local client (for example, outbound requests to `vscode.dev` in {% data variables.product.prodname_vscode %}). Find the documentation for your chosen client, for example: diff --git a/content/webhooks/testing-and-troubleshooting-webhooks/testing-webhooks.md b/content/webhooks/testing-and-troubleshooting-webhooks/testing-webhooks.md index f3c0788e0f4f..b0f914212606 100644 --- a/content/webhooks/testing-and-troubleshooting-webhooks/testing-webhooks.md +++ b/content/webhooks/testing-and-troubleshooting-webhooks/testing-webhooks.md @@ -44,6 +44,8 @@ In order to test your webhook code locally on your computer or codespace, you ca The following sections demonstrate how to use smee.io to provide a webhook proxy URL and forward webhooks. +Smee is intended for development and testing only. Smee channels are not authenticated or secure, so anyone with your webhook proxy URL can see the payloads sent to it. Alternatively, you can use a tool like [ngrok](https://ngrok.com/docs/getting-started/), [localtunnel](https://localtunnel.github.io/www/), or the [Hookdeck Console](https://console.hookdeck.com?provider=github) that exposes your local machine to the internet to receive the payloads. If you use one of these tools, use the public URL that it provides as your webhook URL, and skip the smee-specific steps in the following sections. + For specific examples of code and testing steps, see [AUTOTITLE](/webhooks/using-webhooks/handling-webhook-deliveries). ### Get a webhook proxy URL diff --git a/data/release-notes/enterprise-server/3-19/0-rc1.yml b/data/release-notes/enterprise-server/3-19/0-rc1.yml index 9afe09b2cf30..1cbe4a5c8066 100644 --- a/data/release-notes/enterprise-server/3-19/0-rc1.yml +++ b/data/release-notes/enterprise-server/3-19/0-rc1.yml @@ -239,7 +239,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | Users may see a mismatch between repository-level Dependabot alerts and the overall Security Risk dashboard metrics. This can be resolved by reloading the page. - | diff --git a/data/release-notes/enterprise-server/3-19/0.yml b/data/release-notes/enterprise-server/3-19/0.yml index 115624d63719..c4c0619a03c4 100644 --- a/data/release-notes/enterprise-server/3-19/0.yml +++ b/data/release-notes/enterprise-server/3-19/0.yml @@ -244,7 +244,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | Users may see a mismatch between repository-level Dependabot alerts and the overall Security Risk dashboard metrics. This can be resolved by reloading the page. - | diff --git a/data/release-notes/enterprise-server/3-19/1.yml b/data/release-notes/enterprise-server/3-19/1.yml index fec764cea93d..3b5a37499d10 100644 --- a/data/release-notes/enterprise-server/3-19/1.yml +++ b/data/release-notes/enterprise-server/3-19/1.yml @@ -90,7 +90,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if Dependabot is enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/10.yml b/data/release-notes/enterprise-server/3-19/10.yml index 6694075889f2..1addd6ebf785 100644 --- a/data/release-notes/enterprise-server/3-19/10.yml +++ b/data/release-notes/enterprise-server/3-19/10.yml @@ -90,7 +90,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if Dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/11.yml b/data/release-notes/enterprise-server/3-19/11.yml index bf5a1770e6ce..93b554c47c92 100644 --- a/data/release-notes/enterprise-server/3-19/11.yml +++ b/data/release-notes/enterprise-server/3-19/11.yml @@ -80,7 +80,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if Dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/12.yml b/data/release-notes/enterprise-server/3-19/12.yml index 2f8ac4c746b2..4a0cba63695d 100644 --- a/data/release-notes/enterprise-server/3-19/12.yml +++ b/data/release-notes/enterprise-server/3-19/12.yml @@ -99,7 +99,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if Dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/2.yml b/data/release-notes/enterprise-server/3-19/2.yml index 4569b34f91f8..dfc08a9cce12 100644 --- a/data/release-notes/enterprise-server/3-19/2.yml +++ b/data/release-notes/enterprise-server/3-19/2.yml @@ -89,7 +89,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/3.yml b/data/release-notes/enterprise-server/3-19/3.yml index 29cd403fb188..eb05d26b6ce5 100644 --- a/data/release-notes/enterprise-server/3-19/3.yml +++ b/data/release-notes/enterprise-server/3-19/3.yml @@ -89,7 +89,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the Actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if Dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/4.yml b/data/release-notes/enterprise-server/3-19/4.yml index 5898a812293a..09bf037ddfcd 100644 --- a/data/release-notes/enterprise-server/3-19/4.yml +++ b/data/release-notes/enterprise-server/3-19/4.yml @@ -87,7 +87,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the Actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if Dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/5.yml b/data/release-notes/enterprise-server/3-19/5.yml index a2d4f11946f4..4090e896df69 100644 --- a/data/release-notes/enterprise-server/3-19/5.yml +++ b/data/release-notes/enterprise-server/3-19/5.yml @@ -124,7 +124,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/6.yml b/data/release-notes/enterprise-server/3-19/6.yml index 7598cb5394f4..2f5c69ade95e 100644 --- a/data/release-notes/enterprise-server/3-19/6.yml +++ b/data/release-notes/enterprise-server/3-19/6.yml @@ -90,7 +90,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/7.yml b/data/release-notes/enterprise-server/3-19/7.yml index c2adc2756dac..f0b6783a0f42 100644 --- a/data/release-notes/enterprise-server/3-19/7.yml +++ b/data/release-notes/enterprise-server/3-19/7.yml @@ -65,7 +65,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/8.yml b/data/release-notes/enterprise-server/3-19/8.yml index e5618b61dee3..758405be29f5 100644 --- a/data/release-notes/enterprise-server/3-19/8.yml +++ b/data/release-notes/enterprise-server/3-19/8.yml @@ -83,7 +83,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the GitHub Actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if Dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-19/9.yml b/data/release-notes/enterprise-server/3-19/9.yml index 5f7a3123c32f..3025cfbba1f7 100644 --- a/data/release-notes/enterprise-server/3-19/9.yml +++ b/data/release-notes/enterprise-server/3-19/9.yml @@ -96,7 +96,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | The setting to define private registries at the organization level for code scanning is only available if dependabot is also enabled for the instance. - | diff --git a/data/release-notes/enterprise-server/3-20/0-rc1.yml b/data/release-notes/enterprise-server/3-20/0-rc1.yml index af0f705cd9de..150f7d2d59ca 100644 --- a/data/release-notes/enterprise-server/3-20/0-rc1.yml +++ b/data/release-notes/enterprise-server/3-20/0-rc1.yml @@ -200,7 +200,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-20/0.yml b/data/release-notes/enterprise-server/3-20/0.yml index bcc568cb5943..10274f13da98 100644 --- a/data/release-notes/enterprise-server/3-20/0.yml +++ b/data/release-notes/enterprise-server/3-20/0.yml @@ -196,7 +196,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-20/1.yml b/data/release-notes/enterprise-server/3-20/1.yml index 063b93cb95a9..4b584d0e63e2 100644 --- a/data/release-notes/enterprise-server/3-20/1.yml +++ b/data/release-notes/enterprise-server/3-20/1.yml @@ -120,7 +120,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-20/2.yml b/data/release-notes/enterprise-server/3-20/2.yml index acb18c4765ef..98a0f7166b3e 100644 --- a/data/release-notes/enterprise-server/3-20/2.yml +++ b/data/release-notes/enterprise-server/3-20/2.yml @@ -88,7 +88,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-20/3.yml b/data/release-notes/enterprise-server/3-20/3.yml index d77ffd7b1da9..4327de1523eb 100644 --- a/data/release-notes/enterprise-server/3-20/3.yml +++ b/data/release-notes/enterprise-server/3-20/3.yml @@ -61,7 +61,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-20/4.yml b/data/release-notes/enterprise-server/3-20/4.yml index cbb8813894bc..1f8b0f55b7c5 100644 --- a/data/release-notes/enterprise-server/3-20/4.yml +++ b/data/release-notes/enterprise-server/3-20/4.yml @@ -81,7 +81,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the GitHub Actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-20/5.yml b/data/release-notes/enterprise-server/3-20/5.yml index 513eecf0e1b2..6c9421b24e0b 100644 --- a/data/release-notes/enterprise-server/3-20/5.yml +++ b/data/release-notes/enterprise-server/3-20/5.yml @@ -98,7 +98,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-20/6.yml b/data/release-notes/enterprise-server/3-20/6.yml index bb69e46d965c..b9ffca1dcb42 100644 --- a/data/release-notes/enterprise-server/3-20/6.yml +++ b/data/release-notes/enterprise-server/3-20/6.yml @@ -93,7 +93,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-20/7.yml b/data/release-notes/enterprise-server/3-20/7.yml index bdcd68ceb8ee..48fe3b918fd3 100644 --- a/data/release-notes/enterprise-server/3-20/7.yml +++ b/data/release-notes/enterprise-server/3-20/7.yml @@ -86,7 +86,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | Enterprise owners who apply a security configuration, such as Secret Scanning or Code Scanning, to all repositories in an enterprise may experience increased system load and degraded performance because GitHub Enterprise Server simultaneously queues enablement jobs for every organization. To reduce the impact, apply security configurations at the organization level and enable them incrementally while monitoring system performance. - | diff --git a/data/release-notes/enterprise-server/3-20/8.yml b/data/release-notes/enterprise-server/3-20/8.yml index 72eadf2898eb..6151eb1b931e 100644 --- a/data/release-notes/enterprise-server/3-20/8.yml +++ b/data/release-notes/enterprise-server/3-20/8.yml @@ -102,7 +102,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-21/0-rc1.yml b/data/release-notes/enterprise-server/3-21/0-rc1.yml index d7cd04bf21e3..a1a86e8d3ff1 100644 --- a/data/release-notes/enterprise-server/3-21/0-rc1.yml +++ b/data/release-notes/enterprise-server/3-21/0-rc1.yml @@ -266,7 +266,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-21/0.yml b/data/release-notes/enterprise-server/3-21/0.yml index 3d3a1946a7f2..c0a7c0ec1298 100644 --- a/data/release-notes/enterprise-server/3-21/0.yml +++ b/data/release-notes/enterprise-server/3-21/0.yml @@ -269,7 +269,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-21/1.yml b/data/release-notes/enterprise-server/3-21/1.yml index 7d1f7bcb0174..79f3c11ef308 100644 --- a/data/release-notes/enterprise-server/3-21/1.yml +++ b/data/release-notes/enterprise-server/3-21/1.yml @@ -33,7 +33,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-21/2.yml b/data/release-notes/enterprise-server/3-21/2.yml index 8d980572a1c5..1fb3ac8ab1e8 100644 --- a/data/release-notes/enterprise-server/3-21/2.yml +++ b/data/release-notes/enterprise-server/3-21/2.yml @@ -80,7 +80,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-21/3.yml b/data/release-notes/enterprise-server/3-21/3.yml index 0c5fa7c46ac3..8b2d5e8253fd 100644 --- a/data/release-notes/enterprise-server/3-21/3.yml +++ b/data/release-notes/enterprise-server/3-21/3.yml @@ -94,7 +94,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-21/4.yml b/data/release-notes/enterprise-server/3-21/4.yml index bd695b015071..0976a7d310e9 100644 --- a/data/release-notes/enterprise-server/3-21/4.yml +++ b/data/release-notes/enterprise-server/3-21/4.yml @@ -92,7 +92,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling secret scanning or code scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-21/5.yml b/data/release-notes/enterprise-server/3-21/5.yml index b06eb725113d..5fd27da5fc24 100644 --- a/data/release-notes/enterprise-server/3-21/5.yml +++ b/data/release-notes/enterprise-server/3-21/5.yml @@ -88,7 +88,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | Enterprise owners who apply a security configuration, such as Secret Scanning or Code Scanning, to all repositories in an enterprise may experience increased system load and degraded performance because GitHub Enterprise Server simultaneously queues enablement jobs for every organization. To reduce the impact, apply security configurations at the organization level and enable them incrementally while monitoring system performance. - | diff --git a/data/release-notes/enterprise-server/3-21/6.yml b/data/release-notes/enterprise-server/3-21/6.yml index bf24a813ede3..271f1dd1a627 100644 --- a/data/release-notes/enterprise-server/3-21/6.yml +++ b/data/release-notes/enterprise-server/3-21/6.yml @@ -110,7 +110,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-22/0-rc1.yml b/data/release-notes/enterprise-server/3-22/0-rc1.yml index 0e2694b0bafb..32fc3b5552f2 100644 --- a/data/release-notes/enterprise-server/3-22/0-rc1.yml +++ b/data/release-notes/enterprise-server/3-22/0-rc1.yml @@ -222,7 +222,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to {% data variables.product.prodname_ghe_server %} 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the {% data variables.product.prodname_registry %} service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to {% data variables.product.prodname_registry %}. + When publishing npm packages in a workflow after restoring from a backup to {% data variables.product.prodname_ghe_server %}, you may encounter a `401 Unauthorized` error from the {% data variables.product.prodname_registry %} service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to {% data variables.product.prodname_registry %}. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling {% data variables.product.prodname_secret_scanning_caps %} or {% data variables.product.prodname_code_scanning_caps %} across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-22/0.yml b/data/release-notes/enterprise-server/3-22/0.yml index 4d43b818670c..58603f5ed3b1 100644 --- a/data/release-notes/enterprise-server/3-22/0.yml +++ b/data/release-notes/enterprise-server/3-22/0.yml @@ -226,7 +226,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to {% data variables.product.prodname_ghe_server %} 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the {% data variables.product.prodname_registry %} service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to {% data variables.product.prodname_registry %}. + When publishing npm packages in a workflow after restoring from a backup to {% data variables.product.prodname_ghe_server %}, you may encounter a `401 Unauthorized` error from the {% data variables.product.prodname_registry %} service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to {% data variables.product.prodname_registry %}. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling {% data variables.product.prodname_secret_scanning_caps %} or {% data variables.product.prodname_code_scanning_caps %} across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-22/1.yml b/data/release-notes/enterprise-server/3-22/1.yml index 9c9a5e5e3b69..2a7abc49d375 100644 --- a/data/release-notes/enterprise-server/3-22/1.yml +++ b/data/release-notes/enterprise-server/3-22/1.yml @@ -104,7 +104,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-22/2.yml b/data/release-notes/enterprise-server/3-22/2.yml index de519855b999..ad95440ab5fb 100644 --- a/data/release-notes/enterprise-server/3-22/2.yml +++ b/data/release-notes/enterprise-server/3-22/2.yml @@ -55,7 +55,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server 3.13.5.gm4 or 3.14.2.gm3, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. + When publishing npm packages in a workflow after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token is valid and includes the correct scopes for publishing to GitHub Packages. [Updated: 2026-11-10] - | When applying an enterprise security configuration to all repositories (for example, enabling Secret Scanning or Code Scanning across all repositories), the system immediately enqueues enablement jobs for every organization in the enterprise simultaneously. For enterprises with a large number of repositories, this can result in significant system load and potential performance degradation. If you manage a large enterprise with many organizations and repositories, we recommend applying security configurations at the organization level rather than at the enterprise level in the UI. This allows you to enable security features incrementally and monitor system performance as you roll out changes. - | diff --git a/data/release-notes/enterprise-server/3-22/3.yml b/data/release-notes/enterprise-server/3-22/3.yml index 1d5b080d2741..84b92bbbf0ad 100644 --- a/data/release-notes/enterprise-server/3-22/3.yml +++ b/data/release-notes/enterprise-server/3-22/3.yml @@ -95,7 +95,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - When publishing npm packages in a workflow shortly after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This has been confirmed on 3.13.5.gm4 and 3.14.2.gm3, and it may also affect later supported versions — applicability to current releases is still being confirmed. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token used for publishing is valid and includes the correct scopes for the GitHub Packages service. + When publishing npm packages in a workflow shortly after restoring from a backup to GitHub Enterprise Server, you may encounter a `401 Unauthorized` error from the GitHub Packages service. This has been confirmed on earlier releases and may also affect later supported versions. Applicability to current releases is still being confirmed. This can happen if the restore is from an N-1 or N-2 version and the workflow targets the npm endpoint on the backup instance. To avoid this issue, ensure the access token used for publishing is valid and includes the correct scopes for the GitHub Packages service. [Updated: 2026-11-10] - | On instances with multiple Git storage nodes in a voting configuration, including cluster and geo-replication high availability topologies, upgrading may fail to correctly install Actions that ship with the new version. In some cases, previous versions of these Actions remain on the instance. To resolve this issue, run the following commands on the primary node: `ghe-config --unset 'app.actions.actions-repos-sha1sum'`, `ghe-config-apply`, and `/usr/local/share/enterprise/ghe-run-init-actions-graph`. - | diff --git a/data/variables/README.md b/data/variables/README.md index f8fa22a8e6b8..56c968a514fb 100644 --- a/data/variables/README.md +++ b/data/variables/README.md @@ -2,7 +2,7 @@ Variables are short strings of reusable text. -The YAML files in this directory each contain multiple variables. +The YAML files in this directory each contain multiple variables. Define each variable as a string value with a top-level key. You can organize the files in subdirectories. The *path*, *filename*, and *keys* within each YAML file determine what its path will be in the data object. @@ -10,18 +10,14 @@ For example, given a file `data/variables/foo/bar.yml`: ```yaml # multiple short strings in one file -meaning_of_life: 42 - -# and they can be nested if needed -nested: - values: - too: Yes! +meaning_of_life: '42' +affirmation: 'Yes!' ``` Its values would be accessible as: ``` -{% data foo.bar.meaning_of_life %} +{% data variables.foo.bar.meaning_of_life %} -{% data foo.bar.nested.values.too %} +{% data variables.foo.bar.affirmation %} ``` diff --git a/src/graphql/data/fpt/category-map.json b/src/graphql/data/fpt/category-map.json index 86f782eade1a..2495abce2deb 100644 --- a/src/graphql/data/fpt/category-map.json +++ b/src/graphql/data/fpt/category-map.json @@ -1279,6 +1279,7 @@ "milestoneorderfield": "issues", "milestonestate": "issues", "pendingissuesuggestionkind": "issues", + "pinnedissuefieldorderfield": "issues", "trackedissuestates": "issues", "discussionclosereason": "discussions", "discussionorderfield": "discussions", @@ -1650,6 +1651,7 @@ "pendingissuesuggestionref": "issues", "pinissuecommentinput": "issues", "pinissueinput": "issues", + "pinnedissuefieldorder": "issues", "rejectpendingissuesuggestionsinput": "issues", "removeassigneesfromassignableinput": "issues", "removeblockedbyinput": "issues", diff --git a/src/graphql/data/fpt/changelog.json b/src/graphql/data/fpt/changelog.json index 373159c75360..ecd397f523dc 100644 --- a/src/graphql/data/fpt/changelog.json +++ b/src/graphql/data/fpt/changelog.json @@ -1,4 +1,22 @@ [ + { + "schemaChanges": [ + { + "title": "The GraphQL schema includes these changes:", + "changes": [ + "

Type PinnedIssueFieldOrder was added

", + "

Input field direction of type OrderDirection! was added to input object type PinnedIssueFieldOrder

", + "

Input field field of type PinnedIssueFieldOrderField! was added to input object type PinnedIssueFieldOrder

", + "

Type PinnedIssueFieldOrderField was added

", + "

Enum value POSITION was added to enum PinnedIssueFieldOrderField

", + "

Argument orderBy: PinnedIssueFieldOrder (with default value) added to field Organization.pinnedIssueFields

" + ] + } + ], + "previewChanges": [], + "upcomingChanges": [], + "date": "2026-11-10" + }, { "schemaChanges": [ { diff --git a/src/graphql/data/fpt/schema-issues.json b/src/graphql/data/fpt/schema-issues.json index df9c24df4a2e..0ac630efc5b3 100644 --- a/src/graphql/data/fpt/schema-issues.json +++ b/src/graphql/data/fpt/schema-issues.json @@ -10651,6 +10651,20 @@ ], "category": "issues" }, + { + "name": "PinnedIssueFieldOrderField", + "id": "pinnedissuefieldorderfield", + "href": "/graphql/reference/issues#enum-pinnedissuefieldorderfield", + "description": "

Properties by which pinned issue fields can be ordered.

", + "isDeprecated": false, + "values": [ + { + "name": "POSITION", + "description": "

Order pinned issue fields by their configured pinned position.

" + } + ], + "category": "issues" + }, { "name": "TrackedIssueStates", "id": "trackedissuestates", @@ -13008,6 +13022,30 @@ ], "category": "issues" }, + { + "name": "PinnedIssueFieldOrder", + "id": "pinnedissuefieldorder", + "href": "/graphql/reference/issues#input-object-pinnedissuefieldorder", + "description": "

Ordering options for pinned issue field connections.

", + "isDeprecated": false, + "inputFields": [ + { + "name": "direction", + "description": "

The ordering direction.

", + "type": "OrderDirection!", + "id": "orderdirection", + "href": "/graphql/reference/meta#enum-orderdirection" + }, + { + "name": "field", + "description": "

The field to order pinned issue fields by.

", + "type": "PinnedIssueFieldOrderField!", + "id": "pinnedissuefieldorderfield", + "href": "/graphql/reference/issues#enum-pinnedissuefieldorderfield" + } + ], + "category": "issues" + }, { "name": "RejectPendingIssueSuggestionsInput", "id": "rejectpendingissuesuggestionsinput", diff --git a/src/graphql/data/fpt/schema-orgs.json b/src/graphql/data/fpt/schema-orgs.json index 2c0a602cdfa3..7d992609944c 100644 --- a/src/graphql/data/fpt/schema-orgs.json +++ b/src/graphql/data/fpt/schema-orgs.json @@ -7813,6 +7813,16 @@ "id": "int", "href": "/graphql/reference/other#scalar-int" } + }, + { + "name": "orderBy", + "defaultValue": "{field: POSITION, direction: ASC}", + "description": "

The order in which to return pinned issue fields.

", + "type": { + "name": "PinnedIssueFieldOrder", + "id": "pinnedissuefieldorder", + "href": "/graphql/reference/issues#input-object-pinnedissuefieldorder" + } } ] }, diff --git a/src/graphql/data/fpt/schema.docs.graphql b/src/graphql/data/fpt/schema.docs.graphql index b73ccbdffe3e..c7bb99905f1b 100644 --- a/src/graphql/data/fpt/schema.docs.graphql +++ b/src/graphql/data/fpt/schema.docs.graphql @@ -36532,6 +36532,11 @@ type Organization implements Actor & Returns the last _n_ elements from the list. """ last: Int + + """ + The order in which to return pinned issue fields. + """ + orderBy: PinnedIssueFieldOrder = {field: POSITION, direction: ASC} ): IssueFieldsConnection """ @@ -40104,6 +40109,31 @@ type PinnedIssueEdge { node: PinnedIssue } +""" +Ordering options for pinned issue field connections. +""" +input PinnedIssueFieldOrder @docsCategory(name: "issues") { + """ + The ordering direction. + """ + direction: OrderDirection! + + """ + The field to order pinned issue fields by. + """ + field: PinnedIssueFieldOrderField! +} + +""" +Properties by which pinned issue fields can be ordered. +""" +enum PinnedIssueFieldOrderField @docsCategory(name: "issues") { + """ + Order pinned issue fields by their configured pinned position. + """ + POSITION +} + """ An ISO-8601 encoded UTC date string with millisecond precision. """ diff --git a/src/graphql/data/ghec/category-map.json b/src/graphql/data/ghec/category-map.json index 86f782eade1a..2495abce2deb 100644 --- a/src/graphql/data/ghec/category-map.json +++ b/src/graphql/data/ghec/category-map.json @@ -1279,6 +1279,7 @@ "milestoneorderfield": "issues", "milestonestate": "issues", "pendingissuesuggestionkind": "issues", + "pinnedissuefieldorderfield": "issues", "trackedissuestates": "issues", "discussionclosereason": "discussions", "discussionorderfield": "discussions", @@ -1650,6 +1651,7 @@ "pendingissuesuggestionref": "issues", "pinissuecommentinput": "issues", "pinissueinput": "issues", + "pinnedissuefieldorder": "issues", "rejectpendingissuesuggestionsinput": "issues", "removeassigneesfromassignableinput": "issues", "removeblockedbyinput": "issues", diff --git a/src/graphql/data/ghec/schema-issues.json b/src/graphql/data/ghec/schema-issues.json index df9c24df4a2e..0ac630efc5b3 100644 --- a/src/graphql/data/ghec/schema-issues.json +++ b/src/graphql/data/ghec/schema-issues.json @@ -10651,6 +10651,20 @@ ], "category": "issues" }, + { + "name": "PinnedIssueFieldOrderField", + "id": "pinnedissuefieldorderfield", + "href": "/graphql/reference/issues#enum-pinnedissuefieldorderfield", + "description": "

Properties by which pinned issue fields can be ordered.

", + "isDeprecated": false, + "values": [ + { + "name": "POSITION", + "description": "

Order pinned issue fields by their configured pinned position.

" + } + ], + "category": "issues" + }, { "name": "TrackedIssueStates", "id": "trackedissuestates", @@ -13008,6 +13022,30 @@ ], "category": "issues" }, + { + "name": "PinnedIssueFieldOrder", + "id": "pinnedissuefieldorder", + "href": "/graphql/reference/issues#input-object-pinnedissuefieldorder", + "description": "

Ordering options for pinned issue field connections.

", + "isDeprecated": false, + "inputFields": [ + { + "name": "direction", + "description": "

The ordering direction.

", + "type": "OrderDirection!", + "id": "orderdirection", + "href": "/graphql/reference/meta#enum-orderdirection" + }, + { + "name": "field", + "description": "

The field to order pinned issue fields by.

", + "type": "PinnedIssueFieldOrderField!", + "id": "pinnedissuefieldorderfield", + "href": "/graphql/reference/issues#enum-pinnedissuefieldorderfield" + } + ], + "category": "issues" + }, { "name": "RejectPendingIssueSuggestionsInput", "id": "rejectpendingissuesuggestionsinput", diff --git a/src/graphql/data/ghec/schema-orgs.json b/src/graphql/data/ghec/schema-orgs.json index 2c0a602cdfa3..7d992609944c 100644 --- a/src/graphql/data/ghec/schema-orgs.json +++ b/src/graphql/data/ghec/schema-orgs.json @@ -7813,6 +7813,16 @@ "id": "int", "href": "/graphql/reference/other#scalar-int" } + }, + { + "name": "orderBy", + "defaultValue": "{field: POSITION, direction: ASC}", + "description": "

The order in which to return pinned issue fields.

", + "type": { + "name": "PinnedIssueFieldOrder", + "id": "pinnedissuefieldorder", + "href": "/graphql/reference/issues#input-object-pinnedissuefieldorder" + } } ] }, diff --git a/src/graphql/data/ghec/schema.docs.graphql b/src/graphql/data/ghec/schema.docs.graphql index b73ccbdffe3e..c7bb99905f1b 100644 --- a/src/graphql/data/ghec/schema.docs.graphql +++ b/src/graphql/data/ghec/schema.docs.graphql @@ -36532,6 +36532,11 @@ type Organization implements Actor & Returns the last _n_ elements from the list. """ last: Int + + """ + The order in which to return pinned issue fields. + """ + orderBy: PinnedIssueFieldOrder = {field: POSITION, direction: ASC} ): IssueFieldsConnection """ @@ -40104,6 +40109,31 @@ type PinnedIssueEdge { node: PinnedIssue } +""" +Ordering options for pinned issue field connections. +""" +input PinnedIssueFieldOrder @docsCategory(name: "issues") { + """ + The ordering direction. + """ + direction: OrderDirection! + + """ + The field to order pinned issue fields by. + """ + field: PinnedIssueFieldOrderField! +} + +""" +Properties by which pinned issue fields can be ordered. +""" +enum PinnedIssueFieldOrderField @docsCategory(name: "issues") { + """ + Order pinned issue fields by their configured pinned position. + """ + POSITION +} + """ An ISO-8601 encoded UTC date string with millisecond precision. """