Repo sync

content/actions/concepts/security/index.md

@@ -1,12 +1,13 @@
 ---
 title: Security in GitHub Actions
 shortTitle: Security
-intro: "Learn about security as a concept in GitHub Actions."
+intro: Learn about security as a concept in GitHub Actions.
 versions:
   fpt: '*'
   ghes: '*'
   ghec: '*'
 children:
-  - /about-secrets
+  - /secrets
   - /about-security-hardening-with-openid-connect
 ---
+

content/actions/concepts/security/about-secrets.md → content/actions/concepts/security/secrets.md

@@ -1,45 +1,31 @@
 ---
-title: About secrets
-intro: 'Learn about secrets as they''re used in GitHub Actions.'
+title: Secrets
+intro: Learn about secrets as they are used in {% data variables.product.prodname_actions %} workflows.
 versions:
   fpt: '*'
   ghes: '*'
   ghec: '*'
 redirect_from:
   - /actions/security-for-github-actions/security-guides/about-secrets
+  - /actions/concepts/security/about-secrets
 ---
 
-{% data reusables.actions.enterprise-github-hosted-runners %}
-
 ## About secrets
 
 Secrets allow you to store sensitive information in your organization, repository, or repository environments. Secrets are variables that you create to use in {% data variables.product.prodname_actions %} workflows in an organization, repository, or repository environment.
 
 {% data variables.product.prodname_actions %} can only read a secret if you explicitly include the secret in a workflow.
 
-## Naming your secrets
-
->[!TIP]
-> To help ensure that {% data variables.product.prodname_dotcom %} redacts your secrets in logs correctly, avoid using structured data as the values of secrets.
-
-The following rules apply to secret names:
-
-{% data reusables.actions.actions-secrets-and-variables-naming %}
-
-{% data reusables.codespaces.secret-precedence %} Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.
-
-## Using your secrets in workflows
-
-{% data reusables.actions.secrets-redaction-warning %}
+## Organization-level secrets
 
 {% data reusables.actions.secrets-org-level-overview %}
 
+When creating a secret for an organization, you can use a policy to limit access by repository. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories.
+
 For environment secrets, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
 
 To make a secret available to an action, you must set the secret as an input or environment variable in your workflow file. Review the action's README file to learn about which inputs and environment variables the action expects. See [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsenv).
 
-Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
-
 ## Limiting credential permissions
 
 When generating credentials, we recommend that you grant the minimum permissions possible. For example, instead of using personal credentials, use [deploy keys](/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys) or a service account. Consider granting read-only permissions if that's all that is needed, and limit access as much as possible.
@@ -48,6 +34,18 @@ When generating a {% data variables.product.pat_v1 %}, select the fewest scopes
 
 Instead of using a {% data variables.product.pat_generic %}, consider using a {% data variables.product.prodname_github_app %}, which uses fine-grained permissions and short lived tokens, similar to a {% data variables.product.pat_v2 %}. Unlike a {% data variables.product.pat_generic %}, a {% data variables.product.prodname_github_app %} is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see [AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow).
 
+## Automatically redacted secrets
+
+{% data variables.product.prodname_actions %} automatically redacts the contents of all {% data variables.product.prodname_dotcom %} secrets that are printed to workflow logs.
+
+{% data variables.product.prodname_actions %} also redacts information that is recognized as sensitive, but is not stored as a secret. For a list of automatically redacted secrets, see [AUTOTITLE](/actions/reference/secrets-reference#automatically-redacted-secrets).
+
+> [!NOTE] If you would like other types of sensitive information to be automatically redacted, please reach out to us in our [community discussions](https://github.com/orgs/community/discussions?discussions_q=is%3Aopen+label%3AActions).
+
+As a habit of best practice, you should mask all sensitive information that is not a {% data variables.product.prodname_dotcom %} secret by using `::add-mask::VALUE`. This causes the value to be treated as a secret and redacted from logs. For more information about masking data, see [AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions#masking-a-value-in-a-log).
+
+Redacting of secrets is performed by your workflow runners. This means a secret will only be redacted if it was used within a job and is accessible by the runner. If an unredacted secret is sent to a workflow run log, you should delete the log and rotate the secret. For information on deleting logs, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#deleting-logs).
+
 ## Further reading
 
 * [AUTOTITLE](/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions)

content/actions/concepts/workflows-and-actions/variables.md

@@ -20,7 +20,7 @@ You can set your own custom variables or use the default environment variables t
 You can set a custom variable in two ways.
 
 * To define an environment variable for use in a single workflow, you can use the `env` key in the workflow file. For more information, see [Defining environment variables for a single workflow](/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#defining-environment-variables-for-a-single-workflow).
-* To define a configuration variable across multiple workflows, you can define it at the organization, repository, or environment level. For more information, see [Defining configuration variables for multiple workflows](/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#defining-configuration-variables-for-multiple-workflows).
+* To define a configuration variable across multiple workflows, you can define it at the organization, repository, or environment level. When creating a variable in an organization, you can use a policy to limit access by repository. For example, you can grant access to all repositories, or limit access to only private repositories or a specified list of repositories. For more information, see [Defining configuration variables for multiple workflows](/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#defining-configuration-variables-for-multiple-workflows).
 
 > [!WARNING]
 > By default, variables render unmasked in your build outputs. If you need greater security for sensitive information, such as passwords, use secrets instead. For more information, see [AUTOTITLE](/actions/security-for-github-actions/security-guides/about-secrets).

content/actions/how-tos/security-for-github-actions/security-guides/using-secrets-in-github-actions.md

@@ -1,7 +1,7 @@
 ---
 title: Using secrets in GitHub Actions
 shortTitle: Using secrets
-intro: 'Secrets allow you to store sensitive information in your organization, repository, or repository environments.'
+intro: 'Learn how to create secrets at the repository, environment, and organization levels for {% data variables.product.prodname_actions %} workflows.'
 redirect_from:
   - /github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
   - /actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
@@ -19,10 +19,6 @@ versions:
   ghec: '*'
 ---
 
-{% data reusables.actions.enterprise-github-hosted-runners %}
-
-For general information about secrets, see [AUTOTITLE](/actions/security-for-github-actions/security-guides/about-secrets).
-
 ## Creating secrets for a repository
 
 {% data reusables.actions.permissions-statement-secrets-variables-repository %}
@@ -45,8 +41,6 @@ If your repository has environment secrets or can access secrets from the parent
 
 {% cli %}
 
-{% data reusables.cli.cli-learn-more %}
-
 To add a repository secret, use the `gh secret set` subcommand. Replace `secret-name` with the name of your secret.
 
 ```shell
@@ -172,6 +166,8 @@ You can check which access policies are being applied to a secret in your organi
 > * Secrets are not automatically passed to reusable workflows. For more information, see [AUTOTITLE](/actions/using-workflows/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow).
 > {% data reusables.actions.about-oidc-short-overview %}
 
+> [!WARNING] Mask all sensitive information that is not a {% data variables.product.prodname_dotcom %} secret by using `::add-mask::VALUE`. This causes the value to be treated as a secret and redacted from logs.
+
 To provide an action with a secret as an input or environment variable, you can use the `secrets` context to access secrets you've created in your repository. For more information, see [AUTOTITLE](/actions/learn-github-actions/contexts) and [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions).
 
 {% raw %}
@@ -240,19 +236,7 @@ steps:
 
 {% endraw %}
 
-## Limits for secrets
-
-You can store up to 1,000 organization secrets, 100 repository secrets, and 100 environment secrets.
-
-A workflow created in a repository can access the following number of secrets:
-
-* All 100 repository secrets.
-* If the repository is assigned access to more than 100 organization secrets, the workflow can only use the first 100 organization secrets (sorted alphabetically by secret name).
-* All 100 environment secrets.
-
-Secrets are limited to 48 KB in size. To store larger secrets, see the [Storing large secrets](#storing-large-secrets) workaround below.
-
-### Storing large secrets
+## Storing large secrets
 
 To use secrets that are larger than 48 KB, you can use a workaround to store secrets in your repository and save the decryption passphrase as a secret on {% data variables.product.prodname_dotcom %}. For example, you can use `gpg` to encrypt a file containing your secret locally before checking the encrypted file in to your repository on {% data variables.product.prodname_dotcom %}. For more information, see the [gpg manpage](https://www.gnupg.org/gph/de/manual/r1023.html).
 
@@ -330,7 +314,8 @@ To use secrets that are larger than 48 KB, you can use a workaround to store sec
 You can use Base64 encoding to store small binary blobs as secrets. You can then reference the secret in your workflow and decode it for use on the runner. For the size limits, see [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions#limits-for-secrets).
 
 > [!NOTE]
-> Note that Base64 only converts binary to text, and is not a substitute for actual encryption.
+> * Note that Base64 only converts binary to text, and is not a substitute for actual encryption.
+> * Using another shell might require different commands for decoding the secret to a file. On Windows runners, we recommend [using a bash shell](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell) with `shell: bash` to use the commands in the `run` step above.
 
 1. Use `base64` to encode your file into a Base64 string. For example:
 
@@ -374,33 +359,3 @@ You can use Base64 encoding to store small binary blobs as secrets. You can then
            run: |
              openssl x509 -in cert.der -inform DER -text -noout
    ```
-
-> [!NOTE]
-> Using another shell might require different commands for decoding the secret to a file. On Windows runners, we recommend [using a bash shell](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell) with `shell: bash` to use the commands in the `run` step above.
-
-## Redacting secrets from workflow run logs
-
-{% data variables.product.prodname_actions %} automatically redacts the contents of all {% data variables.product.prodname_dotcom %} secrets that are printed to workflow logs.
-
-{% data variables.product.prodname_actions %} also redacts information that is recognized as sensitive, but is not stored as a secret. Currently {% data variables.product.prodname_dotcom %} supports the following:
-
-* 32-byte and 64-byte Azure keys
-* Azure AD client app passwords
-* Azure Cache keys
-* Azure Container Registry keys
-* Azure Function host keys
-* Azure Search keys
-* Database connection strings
-* HTTP Bearer token headers
-* JWTs
-* NPM author tokens
-* NuGet API keys
-* v1 GitHub installation tokens
-* v2 GitHub installation tokens (`ghp`, `gho`, `ghu`, `ghs`, `ghr`)
-* v2 GitHub PATs
-
-> [!NOTE] If you would like other types of sensitive information to be automatically redacted, please reach out to us in our [community discussions](https://github.com/orgs/community/discussions?discussions_q=is%3Aopen+label%3AActions).
-
-As a habit of best practice, you should mask all sensitive information that is not a {% data variables.product.prodname_dotcom %} secret by using `::add-mask::VALUE`. This causes the value to be treated as a secret and redacted from logs. For more information about masking data, see [AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions#masking-a-value-in-a-log).
-
-Redacting of secrets is performed by your workflow runners. This means a secret will only be redacted if it was used within a job and is accessible by the runner. If an unredacted secret is sent to a workflow run log, you should delete the log and rotate the secret. For information on deleting logs, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#deleting-logs).

content/actions/reference/index.md

@@ -11,6 +11,7 @@ children:
   - /events-that-trigger-workflows
   - /workflow-commands-for-github-actions
   - /variables-reference
+  - /secrets-reference
   - /evaluate-expressions-in-workflows-and-actions
   - /contexts-reference
   - /metadata-syntax-reference

content/actions/reference/secrets-reference.md

@@ -0,0 +1,55 @@
+---
+title: Secrets reference
+shortTitle: Secrets reference
+intro: 'Find technical information about secrets in {% data variables.product.prodname_actions %}.'
+versions:
+  fpt: '*'
+  ghec: '*'
+  ghes: '*'
+---
+
+## Naming your secrets
+
+>[!TIP]
+> To help ensure that {% data variables.product.prodname_dotcom %} redacts your secrets in logs correctly, avoid using structured data as the values of secrets.
+
+The following rules apply to secret names:
+
+{% data reusables.actions.actions-secrets-and-variables-naming %}
+
+{% data reusables.codespaces.secret-precedence %} Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.
+
+## Limits for secrets
+
+You can store up to 1,000 organization secrets, 100 repository secrets, and 100 environment secrets.
+
+A workflow created in a repository can access the following number of secrets:
+
+* All 100 repository secrets.
+* If the repository is assigned access to more than 100 organization secrets, the workflow can only use the first 100 organization secrets (sorted alphabetically by secret name).
+* All 100 environment secrets.
+
+Secrets are limited to 48 KB in size. To store larger secrets, see [AUTOTITLE](/actions/how-tos/security-for-github-actions/security-guides/using-secrets-in-github-actions#storing-large-secrets).
+
+## When {% data variables.product.prodname_actions %} reads secrets
+
+Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
+
+## Automatically redacted secrets
+
+{% data variables.product.prodname_dotcom %} automatically redacts the following sensitive information from workflow logs.
+
+* 32-byte and 64-byte Azure keys
+* Azure AD client app passwords
+* Azure Cache keys
+* Azure Container Registry keys
+* Azure Function host keys
+* Azure Search keys
+* Database connection strings
+* HTTP Bearer token headers
+* JWTs
+* NPM author tokens
+* NuGet API keys
+* v1 GitHub installation tokens
+* v2 GitHub installation tokens (`ghp`, `gho`, `ghu`, `ghs`, `ghr`)
+* v2 GitHub PATs

content/copilot/concepts/copilot-billing/understanding-and-managing-requests-in-copilot.md

@@ -92,15 +92,13 @@ If you use **{% data variables.copilot.copilot_free_short %}**, you have access
 |-------------------------------------------------------------------------|--------------------------------|-----------------------|
 | {% data variables.copilot.copilot_gpt_41 %}                             | 0                              | 1                     |
 | {% data variables.copilot.copilot_gpt_4o %}                             | 0                              | 1                     |
-| {% data variables.copilot.copilot_gpt_45 %}                             | 50                             | Not applicable        |
 | {% data variables.copilot.copilot_claude_sonnet_35 %}                   | 1                              | 1                     |
 | {% data variables.copilot.copilot_claude_sonnet_37 %}                   | 1                              | Not applicable        |
 | {% data variables.copilot.copilot_claude_sonnet_37 %} Thinking          | 1.25                           | Not applicable        |
 | {% data variables.copilot.copilot_claude_sonnet_40 %}                   | 1                              | Not applicable        |
 | {% data variables.copilot.copilot_claude_opus %}                        | 10                             | Not applicable        |
 | {% data variables.copilot.copilot_gemini_flash %}                       | 0.25                           | 1                     |
 | {% data variables.copilot.copilot_gemini_25_pro %}                      | 1                              | Not applicable        |
-| {% data variables.copilot.copilot_o1 %}                                 | 10                             | Not applicable        |
 | {% data variables.copilot.copilot_o3 %}                                 | 1                              | Not applicable        |
 | {% data variables.copilot.copilot_o3_mini %}                            | 0.33                           | 1                     |
 | {% data variables.copilot.copilot_o4_mini %}                            | 0.33                           | Not applicable        |
@@ -111,6 +109,6 @@ If you use **{% data variables.copilot.copilot_free_short %}**, you have access
 
 Premium request usage is based on the model’s multiplier and the feature you’re using. For example:
 
-* **Using {% data variables.copilot.copilot_gpt_45 %} in {% data variables.copilot.copilot_chat_short %}**: With a 50× multiplier, one interaction counts as 50 premium requests.
+* **Using {% data variables.copilot.copilot_claude_opus %} in {% data variables.copilot.copilot_chat_short %}**: With a 10× multiplier, one interaction counts as 10 premium requests.
 * **Using {% data variables.copilot.copilot_gpt_41 %} on {% data variables.copilot.copilot_free_short %}**: Each interaction counts as 1 premium request.
 * **Using {% data variables.copilot.copilot_gpt_41 %} on a paid plan**: No premium requests are consumed.