Merge pull request #43650 from github/repo-sync

docs-bot · web-flow · commit 01c5c5b893b4 · 2026-04-02T10:43:04.000-07:00
Repo sync
diff --git a/content/actions/concepts/security/openid-connect.md b/content/actions/concepts/security/openid-connect.md
@@ -120,43 +120,49 @@ For more information, see [AUTOTITLE](/actions/reference/openid-connect-referenc
 
 ## Using repository custom properties as OIDC claims
 
-> [!NOTE]
-> This feature is currently in public preview and is subject to change.
+Organization and enterprise admins can include repository custom properties as claims in OIDC tokens. This enables attribute-based access control (ABAC) policies in your cloud provider, artifact registry, or secrets manager that are driven by repository metadata rather than hard-coded allow lists.
 
-Organization and enterprise admins can include repository custom properties as claims in OIDC tokens. Once added, every repository in the organization or enterprise that has a value set for that custom property will automatically include it in its OIDC tokens, prefixed with `repo_property_`.
+### How custom property claims work
 
-This allows you to create granular access policies that bind directly to your repository metadata, reducing configuration drift and eliminating the need to duplicate governance information across multiple systems.
+The end-to-end flow for using custom properties as OIDC claims is as follows:
+
+1. **Define custom properties.** An organization or enterprise admin creates custom properties (for example, `business_unit`, `data_classification`, or `environment_tier`) and assigns values to repositories. For more information, see [AUTOTITLE](/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization) and [AUTOTITLE](/actions/reference/security/oidc#including-repository-custom-properties-in-oidc-tokens). 
+1. **Enable properties in OIDC tokens.** An organization or enterprise admin selects which custom properties should be included in OIDC tokens, using the settings UI or the REST API.
+1. **Claims appear automatically.** Every workflow run in a repository that has a value set for an enabled property will include that value in its OIDC token, prefixed with `repo_property_`. No workflow-level configuration changes are required.
+1. **Update cloud trust policies.** You update your cloud provider's trust conditions to evaluate the new `repo_property_*` claims, enabling fine-grained, attribute-based access decisions.
+
+Because this builds on {% data variables.product.prodname_dotcom %}'s existing OIDC short-lived credential model, no long-lived secrets are required, and every token is scoped, auditable, and automatically rotated per workflow run.
 
 ### Prerequisites
 
-* Custom properties must already be defined at the organization or enterprise level.
+* Custom properties must already be defined at the organization or enterprise level. For more information, see [AUTOTITLE](/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization).
 * You must be an organization admin or enterprise admin.
 
 ### Adding a custom property to OIDC token claims
 
 To include a custom property in OIDC tokens, use the REST API or the settings UI for your organization or enterprise.
 
-**Using the settings UI:** Navigate to your organization or enterprise's Actions OIDC settings page to view and manage which custom properties are included in OIDC tokens.
-
-![Screenshot of the OIDC settings for an organization or enterprise.](/assets/images/help/actions/actions-oidc-settings.png)
+* **Using the settings UI:** Navigate to your organization or enterprise's Actions OIDC settings page to view and manage which custom properties are included in OIDC tokens.
 
+* **Using the REST API:** Send a `POST` request to the `/orgs/{org}/actions/oidc/customization/properties/repo` endpoint to add a custom property to the OIDC token claims for your organization. For request parameters and full details, see the REST API documentation for managing OIDC custom properties: [AUTOTITLE](/rest/actions/oidc).
 
-* **Using the REST API:** Send a `POST` request to add a custom property to the OIDC token claims for your organization:
+### Example OIDC token with custom properties
 
-### Example OIDC token with a custom property
-
-The following example shows an OIDC token that includes the `workspace_id` custom property:
+The following example shows an OIDC token that includes two custom properties: a single-select property `business_unit` and a string property `workspace_id`. Each custom property appears in the token with the `repo_property_` prefix.
 
 ```json
 {
   "sub": "repo:my-org/my-repo:ref:refs/heads/main",
   "aud": "https://github.com/my-org",
   "repository": "my-org/my-repo",
+  "repository_owner": "my-org",
+  "ref": "refs/heads/main",
+  "repo_property_business_unit": "payments",
   "repo_property_workspace_id": "ws-abc123"
 }
 ```
 
-You can use the `repo_property_*` claims in your cloud provider's trust conditions to create flexible, attribute-based access control policies. For more information, see [AUTOTITLE](/actions/reference/openid-connect-reference#including-repository-custom-properties-in-oidc-tokens).
+You can use the `repo_property_*` claims in your cloud provider's trust conditions to create flexible, attribute-based access control policies. For more information about the claim format, supported property types, and limits, see [AUTOTITLE](/actions/reference/openid-connect-reference#including-repository-custom-properties-in-oidc-tokens).
 
 {% endif %}
 
diff --git a/content/actions/reference/security/oidc.md b/content/actions/reference/security/oidc.md
@@ -227,40 +227,74 @@ After this setting is applied, the JWT will contain the updated `iss` value. In
 
 ### Including repository custom properties in OIDC tokens
 
-> [!NOTE]
-> This feature is currently in public preview and is subject to change.
-
-Organization and enterprise admins can select repository custom properties to include as claims in Actions OIDC tokens. Once a custom property is added to the OIDC configuration, every repository in the organization or enterprise that has a value set for that property will automatically include it in its OIDC tokens. The property name appears in the token prefixed with `repo_property_`.
+Organization and enterprise admins can select repository custom properties to include as claims in {% data variables.product.prodname_actions %} OIDC tokens. Once a custom property is added to the OIDC configuration, every repository in the organization or enterprise that has a value set for that property will automatically include it in its OIDC tokens. The property name appears in the token prefixed with `repo_property_`.
 
 This allows you to create attribute-based access control (ABAC) policies in your cloud provider that bind directly to your repository metadata, reducing configuration drift and eliminating the need to manage separate access configuration for each repository.
 
+#### Claim format
+
+Each enabled custom property appears as a separate claim in the OIDC token. The claim name is the property name prefixed with `repo_property_`.
+
+| Custom property name | Claim name in OIDC token |
+| --- | --- |
+| `business_unit` | `repo_property_business_unit` |
+| `workspace_id` | `repo_property_workspace_id` |
+| `data_classification` | `repo_property_data_classification` |
+
+#### Supported property types
+
+The following custom property types are supported as OIDC claims. The value representation in the token depends on the property type.
+
+| Property type | Example value in OIDC token | Notes |
+| --- | --- | --- |
+| String | `"repo_property_team": "platform-eng"` | Value appears as a plain string. |
+| Single select | `"repo_property_env_tier": "production"` | The selected option appears as a plain string. |
+| Multi select | `"repo_property_regions": "us-east-1,eu-west-1"` | Multiple selected values are joined into a single comma-separated string. |
+| True/false | `"repo_property_pci_compliant": "true"` | Boolean values appear as the string `"true"` or `"false"`. |
+
+#### Multi-select value representation
+
+When a repository has a multi-select custom property with multiple values selected, the values are joined into a single comma-separated string in the OIDC token. For example, if a repository has a `regions` property with the values `us-east-1` and `eu-west-1`, the claim appears as:
+
+```json
+{
+  "repo_property_regions": "us-east-1,eu-west-1"
+} 
+```
+
+When configuring trust policies in your cloud provider, use string matching or contains checks to evaluate multi-select claims.
+
 #### Prerequisites for including custom properties
 
-* Custom properties must already be defined at the organization or enterprise level.
+* Custom properties must already be defined at the organization or enterprise level. For more information, see [AUTOTITLE](/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization).
 * You must be an organization admin or enterprise admin.
 * After adding a custom property to the OIDC configuration, all repositories in the organization or enterprise that have a value set for that property will automatically include it in their OIDC tokens.
 
 #### Adding a custom property to OIDC token claims
 
 You can manage which custom properties are included in OIDC tokens using the settings UI or the REST API.
 
-* **Using the settings UI:** 
+* **Using the settings UI:**
 
   Navigate to your organization's or enterprise's Actions OIDC settings to view and configure which custom properties are included in OIDC tokens.
 
 * **Using the REST API:**
 
-  To add a custom property to your organization's or enterprise's OIDC token claims, use the REST API. For more information, see [AUTOTITLE](/rest/actions/oidc).
+   To add a custom property to your organization's OIDC token claims, send a `POST` request to the appropriate OIDC custom-property inclusion endpoint. For example:
+   * For an organization: `POST /orgs/{org}/actions/oidc/customization/properties/repo`
+   * For an enterprise: `POST /enterprises/{enterprise}/actions/oidc/customization/properties/repo`
+   For request parameters and full details, see the REST API documentation for managing OIDC custom properties: [AUTOTITLE](/rest/actions/oidc).
 
-#### Example token with a custom property
+#### Example token with custom properties
 
-After a custom property is added to the OIDC configuration, repositories with a value set for that property will include it in their tokens. In the following example, the `workspace_id` custom property appears as `repo_property_workspace_id` in the token:
+After a custom property is added to the OIDC configuration, repositories with a value set for that property will include it in their tokens. In the following example, two custom properties (`business_unit` and `workspace_id`) are included in the token:
 
 ```json
 {
   "sub": "repo:my-org/my-repo:ref:refs/heads/main",
   "aud": "https://github.com/my-org",
   "repository": "my-org/my-repo",
+  "repo_property_business_unit": "payments",
   "repo_property_workspace_id": "ws-abc123"
 }
 ```
diff --git a/content/actions/reference/workflows-and-actions/workflow-syntax.md b/content/actions/reference/workflows-and-actions/workflow-syntax.md
@@ -1182,6 +1182,45 @@ Additional Docker container resource options. For a list of options, see [`docke
 > [!WARNING]
 > The `--network` option is not supported.
 
+{% ifversion fpt or ghec %}
+
+## `jobs.<job_id>.services.<service_id>.command`
+
+Overrides the Docker image's default command (`CMD`). The value is passed as arguments after the image name in the `docker create` command. If you also specify `entrypoint`, `command` provides the arguments to that entrypoint.
+
+### Example of `jobs.<job_id>.services.<service_id>.command`
+
+```yaml
+services:
+  mysql:
+    image: mysql:8
+    command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M
+    env:
+      MYSQL_ROOT_PASSWORD: test
+    ports:
+      - 3306:3306
+```
+
+## `jobs.<job_id>.services.<service_id>.entrypoint`
+
+Overrides the Docker image's default `ENTRYPOINT`. The value is a single string defining the executable to run. Use this when you need to replace the image's entrypoint entirely. You can combine `entrypoint` with `command` to pass arguments to the custom entrypoint.
+
+### Example of `jobs.<job_id>.services.<service_id>.entrypoint`
+
+```yaml
+services:
+  etcd:
+    image: quay.io/coreos/etcd:v3.5.17
+    entrypoint: etcd
+    command: >-
+      --listen-client-urls http://0.0.0.0:2379
+      --advertise-client-urls http://0.0.0.0:2379
+    ports:
+      - 2379:2379
+```
+
+{% endif %}
+
 ## `jobs.<job_id>.uses`
 
 The location and version of a reusable workflow file to run as a job. Use one of the following syntaxes:
diff --git a/content/actions/tutorials/use-containerized-services/use-docker-service-containers.md b/content/actions/tutorials/use-containerized-services/use-docker-service-containers.md
@@ -150,6 +150,43 @@ jobs:
 
 {% endraw %}
 
+{% ifversion fpt or ghec %}
+
+## Customizing service container entrypoints and commands
+
+By default, service containers run with the entrypoint and command defined in the Docker image. You can override these using the `entrypoint` and `command` keys. This is useful when you need to pass flags to a service (such as a database) or swap the image entrypoint entirely, without building a custom wrapper image.
+
+The `command` key overrides the image's default command (`CMD`). Most scenarios only need `command`—the image already has the right entrypoint, you just need to pass flags:
+
+```yaml copy
+services:
+  mysql:
+    image: mysql:8
+    command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M
+    env:
+      MYSQL_ROOT_PASSWORD: test
+    ports:
+      - 3306:3306
+```
+
+The `entrypoint` key overrides the image's `ENTRYPOINT`. You can combine it with `command` to pass arguments to the custom entrypoint:
+
+```yaml copy
+services:
+  etcd:
+    image: quay.io/coreos/etcd:v3.5.17
+    entrypoint: etcd
+    command: >-
+      --listen-client-urls http://0.0.0.0:2379
+      --advertise-client-urls http://0.0.0.0:2379
+    ports:
+      - 2379:2379
+```
+
+The naming and behavior match Docker Compose. For more information, see [`jobs.<job_id>.services.<service_id>.command`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservicesservice_idcommand) and [`jobs.<job_id>.services.<service_id>.entrypoint`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idservicesservice_identrypoint).
+
+{% endif %}
+
 ## Further reading
 
 * [AUTOTITLE](/actions/using-containerized-services/creating-redis-service-containers)
diff --git a/content/copilot/how-tos/copilot-sdk/integrations/microsoft-agent-framework.md b/content/copilot/how-tos/copilot-sdk/integrations/microsoft-agent-framework.md
@@ -8,8 +8,7 @@ product: '{% data reusables.gated-features.copilot-sdk %}'
 contentType: how-tos
 ---
 
-> [!NOTE]
-> {% data variables.copilot.copilot_sdk_short %} is currently in {% data variables.release-phases.technical_preview %}. Functionality and availability are subject to change.
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 Use {% data variables.copilot.copilot_sdk_short %} as an agent provider inside the [Microsoft Agent Framework](https://devblogs.microsoft.com/semantic-kernel/build-ai-agents-with-github-copilot-sdk-and-microsoft-agent-framework/) (MAF) to compose multi-agent workflows alongside Azure OpenAI, Anthropic, and other providers.
 
diff --git a/content/copilot/how-tos/copilot-sdk/sdk-getting-started.md b/content/copilot/how-tos/copilot-sdk/sdk-getting-started.md
@@ -12,8 +12,7 @@ category:
   - Author and optimize with Copilot
 ---
 
-> [!NOTE]
->{% data variables.copilot.copilot_sdk_short %} is currently in {% data variables.release-phases.technical_preview %}. Functionality and availability are subject to change.
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 {% data variables.copilot.copilot_sdk %} lets you build applications powered by {% data variables.product.prodname_copilot %} in your preferred programming language. In this guide, you'll install the SDK using `npm`, send your first message, and add streaming responses.
 
diff --git a/content/copilot/how-tos/copilot-sdk/troubleshooting/debug-copilot-sdk.md b/content/copilot/how-tos/copilot-sdk/troubleshooting/debug-copilot-sdk.md
@@ -8,8 +8,7 @@ versions:
 contentType: how-tos
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 ## Enable debug logging
 
diff --git a/content/copilot/how-tos/copilot-sdk/troubleshooting/debug-mcp-servers.md b/content/copilot/how-tos/copilot-sdk/troubleshooting/debug-mcp-servers.md
@@ -8,8 +8,7 @@ versions:
 contentType: how-tos
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 ## Quick diagnostics
 
diff --git a/content/copilot/how-tos/copilot-sdk/troubleshooting/sdk-and-cli-compatibility.md b/content/copilot/how-tos/copilot-sdk/troubleshooting/sdk-and-cli-compatibility.md
@@ -8,8 +8,7 @@ versions:
 contentType: how-tos
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 {% data variables.copilot.copilot_sdk %} communicates with {% data variables.copilot.copilot_cli %} via JSON-RPC protocol. Features must be explicitly exposed through this protocol to be available in the SDK. Many interactive CLI features are terminal-specific and not available programmatically.
 
diff --git a/content/copilot/how-tos/copilot-sdk/use-hooks/error-handling.md b/content/copilot/how-tos/copilot-sdk/use-hooks/error-handling.md
@@ -10,8 +10,7 @@ category:
   - Author and optimize with Copilot
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 The `onErrorOccurred` hook is called when errors occur during session execution. Use it to:
 
diff --git a/content/copilot/how-tos/copilot-sdk/use-hooks/post-tool-use.md b/content/copilot/how-tos/copilot-sdk/use-hooks/post-tool-use.md
@@ -10,8 +10,7 @@ category:
   - Author and optimize with Copilot
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 The `onPostToolUse` hook is called **after** a tool executes. Use it to:
 
diff --git a/content/copilot/how-tos/copilot-sdk/use-hooks/pre-tool-use.md b/content/copilot/how-tos/copilot-sdk/use-hooks/pre-tool-use.md
@@ -10,8 +10,7 @@ category:
   - Author and optimize with Copilot
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 The `onPreToolUse` hook is called **before** a tool executes. Use it to:
 
diff --git a/content/copilot/how-tos/copilot-sdk/use-hooks/quickstart.md b/content/copilot/how-tos/copilot-sdk/use-hooks/quickstart.md
@@ -11,8 +11,7 @@ category:
   - Author and optimize with Copilot
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 Hooks allow you to intercept and customize the behavior of {% data variables.copilot.copilot_sdk_short %} sessions at key points in the conversation lifecycle. Use hooks to:
 
diff --git a/content/copilot/how-tos/copilot-sdk/use-hooks/session-lifecycle.md b/content/copilot/how-tos/copilot-sdk/use-hooks/session-lifecycle.md
@@ -10,8 +10,7 @@ category:
   - Author and optimize with Copilot
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 Session lifecycle hooks let you respond to session start and end events. Use them to:
 
diff --git a/content/copilot/how-tos/copilot-sdk/use-hooks/user-prompt-submitted.md b/content/copilot/how-tos/copilot-sdk/use-hooks/user-prompt-submitted.md
@@ -10,8 +10,7 @@ category:
   - Author and optimize with Copilot
 ---
 
-> [!NOTE]
-> {% data reusables.copilot.copilot-sdk.technical-preview-note %}
+{% data reusables.copilot.copilot-sdk.technical-preview-note %}
 
 The `onUserPromptSubmitted` hook is called when a user submits a message. Use it to:
 
diff --git a/data/reusables/actions/azure-vnet-supported-regions.md b/data/reusables/actions/azure-vnet-supported-regions.md
@@ -50,4 +50,4 @@ Azure private networking supports arm64 runners in the following regions.
 * `WestUs2`
 * `WestUs3`
 
-If your desired region is not supported, please submit a request for new region availability in [this GitHub form](https://resources.github.com/private-networking-for-github-hosted-runners-with-azure-virtual-networks/). You may also use global virtual network peering to connect virtual networks across Azure regions. For more information, see [Virtual network peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview) in the Azure documentation.
+We will be launching a process to request support for new regions soon. You may also use global virtual network peering to connect virtual networks across Azure regions. For more information, see [Virtual network peering](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview) in the Azure documentation.
diff --git a/data/reusables/copilot/copilot-sdk/technical-preview-note.md b/data/reusables/copilot/copilot-sdk/technical-preview-note.md
@@ -1,2 +1,2 @@
 > [!NOTE]
-> {% data variables.copilot.copilot_sdk_short %} is currently in {% data variables.release-phases.technical_preview %}. Functionality and availability are subject to change.
+> {% data variables.copilot.copilot_sdk_short %} is currently in {% data variables.release-phases.public_preview %}. Functionality and availability are subject to change.
diff --git a/next.config.ts b/next.config.ts
@@ -70,16 +70,16 @@ const config: NextConfig = {
   turbopack: {
     resolveAlias: {
       fs: {
-        browser: './empty.ts', // Point to empty module when fs is requested for browser
+        browser: './stub.ts',
       },
       async_hooks: {
-        browser: './empty.ts', // Point to empty module when async_hooks is requested for browser
+        browser: './stub.ts',
       },
       '@/observability/logger': {
-        browser: './empty.ts',
+        browser: './stub.ts',
       },
       '@/observability/logger/lib/logger-context': {
-        browser: './empty.ts',
+        browser: './stub.ts',
       },
       '@/observability/lib/tracing': {
         browser: './src/observability/lib/tracing.browser.ts',
diff --git a/src/graphql/data/fpt/changelog.json b/src/graphql/data/fpt/changelog.json
diff --git a/src/graphql/data/fpt/schema.docs.graphql b/src/graphql/data/fpt/schema.docs.graphql
diff --git a/src/graphql/data/fpt/schema.json b/src/graphql/data/fpt/schema.json
diff --git a/src/graphql/data/ghec/schema.docs.graphql b/src/graphql/data/ghec/schema.docs.graphql
diff --git a/src/graphql/data/ghec/schema.json b/src/graphql/data/ghec/schema.json
diff --git a/src/landings/components/shared/LandingArticleGridWithFilter.tsx b/src/landings/components/shared/LandingArticleGridWithFilter.tsx
diff --git a/stub.ts b/stub.ts
