Merge pull request #63220 from github/repo-sync

Repo sync

Author: docs-bot

content/copilot/how-tos/copilot-cli/customize-copilot/use-byok-models.md

@@ -49,6 +49,13 @@ You configure your model provider by setting environment variables before starti
 | `COPILOT_PROVIDER_BASE_URL` | Yes | The base URL of your model provider's API endpoint. |
 | `COPILOT_PROVIDER_TYPE` | No | The provider type: `openai` (default), `azure`, or `anthropic`. |
 | `COPILOT_PROVIDER_API_KEY` | No | Your API key for the provider. Not required for providers that do not use authentication, such as a local Ollama instance. |
+| `COPILOT_PROVIDER_BEARER_TOKEN` | No | Bearer token used for provider authentication when API-key authentication is not used. |
+| `COPILOT_PROVIDER_WIRE_API` | No | Specifies the API protocol used when communicating with the provider. |
+| `COPILOT_PROVIDER_AZURE_API_VERSION` | Azure only | The Azure OpenAI API version used for requests. |
+| `COPILOT_PROVIDER_MODEL_ID` | No | The well-known model name used to identify model capabilities and token limits. |
+| `COPILOT_PROVIDER_WIRE_MODEL` | No | The model name sent to the provider API for inference. For Azure OpenAI, use the deployment name. |
+| `COPILOT_PROVIDER_MAX_PROMPT_TOKENS` | No | Maximum number of prompt tokens allowed in a request. |
+| `COPILOT_PROVIDER_MAX_OUTPUT_TOKENS` | No | Maximum number of tokens generated in a response. |
 | `COPILOT_MODEL` | Yes | The model identifier to use. You can also set this with the `--model` command-line flag. |
 
 ## Connecting to an OpenAI-compatible endpoint
@@ -81,17 +88,29 @@ Use the following steps if you are connecting to OpenAI, Ollama, vLLM, Foundry L
 1. Set the environment variables for Azure OpenAI.
 
    ```shell
-   export COPILOT_PROVIDER_BASE_URL=https://YOUR-RESOURCE-NAME.openai.azure.com/openai/deployments/YOUR-DEPLOYMENT-NAME
+   export COPILOT_PROVIDER_BASE_URL=https://YOUR-RESOURCE-NAME.openai.azure.com
    export COPILOT_PROVIDER_TYPE=azure
    export COPILOT_PROVIDER_API_KEY=YOUR-AZURE-API-KEY
+   export COPILOT_PROVIDER_AZURE_API_VERSION=YOUR-AZURE-API-VERSION
+   export COPILOT_PROVIDER_MODEL_ID=YOUR-MODEL-NAME
+   export COPILOT_PROVIDER_WIRE_MODEL=YOUR-DEPLOYMENT-NAME
    export COPILOT_MODEL=YOUR-DEPLOYMENT-NAME
    ```
 
    Replace the following placeholders:
 
-     * `YOUR-RESOURCE-NAME`: your Azure OpenAI resource name
-     * `YOUR-DEPLOYMENT-NAME`: the name of your model deployment
-     * `YOUR-AZURE-API-KEY`: your Azure OpenAI API key
+    * `YOUR-RESOURCE-NAME`: your Azure OpenAI resource name
+    * `YOUR-DEPLOYMENT-NAME`: the deployment name that receives requests
+    * `YOUR-MODEL-NAME`: the underlying model associated with the deployment (for example, `gpt-4o`)
+    * `YOUR-AZURE-API-VERSION`: the Azure OpenAI API version
+    * `YOUR-AZURE-API-KEY`: your Azure OpenAI API key
+
+### Azure-specific environment variables
+
+| Variable | Description |
+|---|---|
+| `COPILOT_PROVIDER_MODEL_ID` | The well-known model name. {% data variables.copilot.copilot_cli_short %} uses this value to identify model capabilities and token limits. |
+| `COPILOT_PROVIDER_WIRE_MODEL` | The Azure OpenAI deployment name. Azure OpenAI routes requests through deployments rather than directly through model names. |
 
 {% data reusables.copilot.copilot-cli.start-cli %}
 

content/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/customize-the-agent-environment.md

@@ -51,7 +51,7 @@ A `copilot-setup-steps.yml` file looks like a normal {% data variables.product.p
 
 Here is a simple example of a `copilot-setup-steps.yml` file for a TypeScript project that clones the project, installs Node.js and downloads and caches the project's dependencies. You should customize this to fit your own project, including its language(s), its dependencies, and the workflow triggers you need. For example, you wouldn't typically run on both `push` and `pull_request`.
 
-```yaml copy
+```yaml
 name: "Copilot Setup Steps"
 
 # Automatically run the setup steps when they are changed to allow for easy validation, and

content/copilot/tutorials/cloud-agent/improve-a-project.md

@@ -79,7 +79,7 @@ Creating this file is optional but is a good idea if you use {% data variables.c
 
    <!-- markdownlint-disable -->
    ```text copy
-   Analyze this repository to understand the dependencies that need to be installed on the development environment to work on the code in this repository. Using this information, and the details about the `copilot-setup-steps.yml` file that are given in https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-environment, add a `.github/workflows/copilot-setup-steps.yml` to this repository. This Actions workflow file should install, in the development environment for {% data variables.copilot.copilot_cloud_agent %}, all of the dependencies necessary to work on the code in this repository. Make sure that the workflow job is named `copilot-setup-steps`.
+   Analyze this repository to understand the dependencies that need to be installed on the development environment to work on the code in this repository. Using this information, and the details about the `copilot-setup-steps.yml` file that are given in https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-environment, add a `.github/workflows/copilot-setup-steps.yml` to this repository. This Actions workflow file should install, in the development environment for {% data variables.copilot.copilot_cloud_agent %}, all of the dependencies necessary to work on the code in this repository. Make sure that the workflow job is named `copilot-setup-steps`, and that the workflow includes a `workflow_dispatch` trigger so that it can be run manually. Choose any other triggers to suit this repository; there's no need to run on both `push` and `pull_request`.
    ```
    <!-- markdownlint-enable -->
 
@@ -97,12 +97,6 @@ Creating this file is optional but is a good idea if you use {% data variables.c
    ```yaml
    on:
      workflow_dispatch:
-     push:
-       paths:
-         - .github/workflows/copilot-setup-steps.yml
-     pull_request:
-       paths:
-         - .github/workflows/copilot-setup-steps.yml
 
    jobs:
      copilot-setup-steps:

content/packages/working-with-a-github-packages-registry/working-with-the-npm-registry.md

@@ -69,7 +69,7 @@ If your instance has subdomain isolation enabled:
 {% endif %}
 
 ```shell
-//{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME/{% endif %}/:_authToken=TOKEN
+//{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}/:_authToken=TOKEN
 ```
 
 {% ifversion ghes %}
@@ -161,7 +161,7 @@ You can use `publishConfig` element in the `package.json` file to specify the re
 
    ```shell
    "publishConfig": {
-     "registry": "https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm. HOSTNAME/{% endif %}"
+     "registry": "https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME/{% endif %}"
    },
    ```
 
@@ -225,23 +225,23 @@ You also need to add the `.npmrc` file to your project so that all requests to i
 
 ### Installing packages from other organizations
 
-By default, you can only use {% data variables.product.prodname_registry %} packages from one organization. If you'd like to route package requests to multiple organizations and users, you can add additional lines to your `.npmrc` file, replacing {% ifversion ghes %}`HOSTNAME` with the host name of {% data variables.location.product_location %} and {% endif %}`NAMESPACE` with the name of the personal account or organization {% ifversion packages-npm-v2 %}to which the package is scoped{% else %}that owns the repository containing the project{% endif %}.
+By default, you can only use {% data variables.product.prodname_registry %} packages from one organization. If you'd like to route package requests to multiple organizations and users, you can add additional lines to your `.npmrc` file, replacing {% ifversion ghes %}`HOSTNAME` with the host name of {% data variables.location.product_location %} and {% endif %}`NAMESPACE1` and `NAMESPACE2` with the names of the personal accounts or organizations {% ifversion packages-npm-v2 %}to which the packages are scoped{% else %}that own the repositories containing the projects{% endif %}.
 
 {% ifversion ghes %}
 If your instance has subdomain isolation enabled:
 {% endif %}
 
 ```shell
-@NAMESPACE:registry=https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}
-@NAMESPACE:registry=https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}
+@NAMESPACE1:registry=https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}
+@NAMESPACE2:registry=https://{% ifversion fpt or ghec %}npm.pkg.github.com{% else %}npm.HOSTNAME{% endif %}
 ```
 
 {% ifversion ghes %}
 If your instance has subdomain isolation disabled:
 
 ```shell
-@NAMESPACE:registry=https://HOSTNAME/_registry/npm
-@NAMESPACE:registry=https://HOSTNAME/_registry/npm
+@NAMESPACE1:registry=https://HOSTNAME/_registry/npm
+@NAMESPACE2:registry=https://HOSTNAME/_registry/npm
 ```
 
 {% endif %}

content/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site.md

@@ -123,6 +123,8 @@ To set up a `www` or custom subdomain, such as `www.example.com` or `blog.exampl
 
 1. Navigate to your DNS provider and create a `CNAME` record that points your subdomain to the default domain for your site. For example, if you want to use the subdomain `www.example.com` for your user site, create a `CNAME` record that points `www.example.com` to `<user>.github.io`. If you want to use the subdomain `another.example.com` for your organization site, create a `CNAME` record that points `another.example.com` to `<organization>.github.io`. The `CNAME` record should always point to `<user>.github.io` or `<organization>.github.io`, excluding the repository name. {% data reusables.pages.contact-dns-provider %} {% data reusables.pages.default-domain-information %}
 
+   These `CNAME` record values are the same for both publicly and privately published {% data variables.product.prodname_pages %} sites. Do not point the `CNAME` record to the unique `*.pages.github.io` subdomain shown in your repository's {% data variables.product.prodname_pages %} settings. Privately published sites are available with {% data variables.product.prodname_ghe_cloud %}. For more information, see [AUTOTITLE](/enterprise-cloud@latest/pages/getting-started-with-github-pages/changing-the-visibility-of-your-github-pages-site){% ifversion fpt %} in the {% data variables.product.prodname_ghe_cloud %} documentation{% endif %}.
+
 {% indented_data_reference reusables.pages.wildcard-dns-warning spaces=3 %}
 {% data reusables.command_line.open_the_multi_os_terminal %}
 1. To confirm that your DNS record configured correctly, use the `dig` command, replacing _WWW.EXAMPLE.COM_ with your subdomain.

content/pull-requests/get-started/reviewing-pull-requests-quickstart.md

@@ -39,7 +39,7 @@ When you know the exact change you'd like, suggest it so the author can apply it
 
 Finish by submitting your review with a decision that tells the author what to do next.
 
-1. Click **Review changes**.
+1. Click **Submit review**.
 1. Add a summary comment.
 1. Select a decision, then click **Submit review**:
 
@@ -50,4 +50,4 @@ Finish by submitting your review with a decision that tells the author what to d
 ## Next steps
 
 * [AUTOTITLE](/pull-requests/concepts/giving-reviews)
-* [AUTOTITLE](/pull-requests/reference/pull-request-reviews)
+* [AUTOTITLE](/pull-requests/reference/pull-request-reviews)