Repo sync

content/actions/how-tos/reuse-automations/reuse-workflows.md

@@ -72,8 +72,14 @@ You can define inputs and secrets, which can be passed from the caller workflow
 
    In the example above, `personal_access_token` is a secret that's defined at the repository or organization level.
 
+   To use an environment secret in a reusable workflow, set `environment` on the job in the reusable workflow. The job that calls the reusable workflow can't use the `environment` keyword. For more information, see [AUTOTITLE](/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments).
+
+   The caller workflow must still pass the secret. Use `secrets: inherit` or pass the secret by name, for example {% raw %}`MY_SECRET: ${{ secrets.MY_SECRET }}`{% endraw %}. You can pass a secret by name even if it only exists in the environment.
+
+   If an environment secret has the same name as a repository or organization secret, the environment secret takes precedence. This applies when the caller uses either `secrets: inherit` or {% raw %}`${{ secrets.MY_SECRET }}`{% endraw %}. The job that sets `environment` receives the environment secret's value.
+
    > [!WARNING]
-   > Environment secrets cannot be passed from the caller workflow as `on.workflow_call` does not support the `environment` keyword. If you include `environment` in the reusable workflow at the job level, the environment secret will be used, and not the secret passed from the caller workflow. For more information, see [AUTOTITLE](/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) and [AUTOTITLE](/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_call).
+   > If the caller workflow doesn't pass an environment secret, the secret resolves to an empty string in the reusable workflow. The workflow run doesn't show an error. To make the workflow run fail instead, set `required: true` for the secret in [`on.workflow_call.secrets`](/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_callsecrets). This setting only checks whether the caller workflow passes the secret. It doesn't check whether the secret has a value.
 
 1. Pass the input or secret from the caller workflow.
 

content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-security-and-analysis-for-your-enterprise.md

@@ -109,6 +109,21 @@ Across all of your enterprise's organizations, you can allow or disallow people
 
 {% endif %}
 
+{% ifversion secret-scanning-actions-logs %}
+
+## Enforcing a policy for secret scanning in {% data variables.product.prodname_actions %} workflow logs
+
+As an enterprise owner, you can choose whether {% data variables.product.github %} scans {% data variables.product.prodname_actions %} workflow logs for secrets. This policy is disabled by default.
+
+When you enable the policy, {% data variables.product.github %} scans the logs of new workflow runs in all repositories in your enterprise where {% data variables.product.prodname_secret_scanning %} is enabled.
+
+{% data reusables.enterprise-accounts.access-enterprise %}
+{% data reusables.enterprise-accounts.policies-tab %}
+{% data reusables.enterprise-accounts.code-security-and-analysis-policies %}
+1. Under "Secret scanning for Actions workflow logs", select the **All repositories** dropdown menu, then click **Enabled** or **Disabled**.
+
+{% endif %}
+
 {% ifversion code-scanning-autofix %}
 
 ## Enforcing a policy to manage the use of {% data variables.copilot.copilot_autofix_short %} in your enterprise's repositories

content/admin/managing-iam/configuring-authentication-for-enterprise-managed-users/configuring-saml-single-sign-on-for-enterprise-managed-users.md

@@ -103,7 +103,6 @@ After the initial configuration of SAML SSO, the only setting you can update on
    > [!NOTE]
    > {% data reusables.enterprise-accounts.emu-password-reset-session %}
 
-1. If you're using a **non-partner IdP** (an IdP other than Okta, PingFederate or Entra ID), before enabling SAML, you must update a setting so that you will be able to set up SCIM using the REST API. See [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-scim-provisioning-for-users#configuring-provisioning-for-other-identity-management-systems).
 {% data reusables.enterprise-accounts.access-enterprise %}
 {% data reusables.enterprise-accounts.identity-provider-tab %}
 {% data reusables.enterprise-accounts.sso-configuration %}
@@ -123,6 +122,7 @@ After the initial configuration of SAML SSO, the only setting you can update on
     > After you require SAML SSO for your enterprise and save SAML settings, the setup user will continue to have access to the enterprise and will remain signed in to GitHub along with the {% data variables.enterprise.prodname_managed_users %} provisioned by your IdP who will also have access to the enterprise.
 
 {% data reusables.enterprise-accounts.download-recovery-codes %}
+1. If you're using a **non-partner IdP** (an IdP other than Okta, PingFederate or Entra ID), after enabling SAML, you must update a setting so that you will be able to set up SCIM using the REST API. See [AUTOTITLE](/admin/managing-iam/provisioning-user-accounts-with-scim/configuring-scim-provisioning-for-users#configuring-provisioning-for-other-identity-management-systems).
 
 ### Enable provisioning
 

content/billing/how-tos/set-up-payment/connect-azure-sub.md

@@ -32,6 +32,8 @@ You can pay for metered usage of {% data variables.product.github %} features th
 
 * You must be logged into Azure as a user who is able to provide tenant-wide admin consent or arrange to work with a Microsoft Entra Global Administrator to configure an admin consent workflow. See [AUTOTITLE](/billing/concepts/azure-subscriptions).
 
+>[!NOTE] If your organization or enterprise has recently signed up for {% data variables.product.prodname_copilot %} with a credit card or PayPal, you may not be able to change your payment method to an Azure subscription. Please [contact {% data variables.product.github %}'s Sales team](https://github.com/enterprise/contact?ref_product=copilot&ref_type=engagement&ref_style=text).
+
 ## Connecting your Azure subscription to an organization or enterprise account
 
 {% data reusables.billing.nav-to-org-or-ent %}

content/code-security/concepts/secret-security/secret-scanning-for-partners.md

@@ -16,7 +16,7 @@ category:
 
 ## About {% data variables.secret-scanning.partner_alerts %}
 
-{% data variables.product.github %} scans public repositories and public npm packages for secrets issued by specific service providers who joined our partnership program, and alerts the relevant service provider whenever a secret is detected in a commit. The service provider validates the string and then decides whether they should revoke the secret, issue a new secret, or contact you directly. Their action will depend on the associated risks to you or them. {% data reusables.secret-scanning.partner-program-link %}
+{% data variables.product.github %} scans public repositories and public npm packages for secrets issued by specific service providers who joined our partnership program, and alerts the relevant service provider whenever a secret is detected in a supported location. The service provider validates the string and then decides whether they should revoke the secret, issue a new secret, or contact you directly. Their action will depend on the associated risks to you or them. {% data reusables.secret-scanning.partner-program-link %}
 
 > [!NOTE]You cannot change the configuration of {% data variables.product.prodname_secret_scanning %} for partner patterns on public repositories.
 

content/code-security/concepts/secret-security/secret-scanning.md

@@ -35,6 +35,25 @@ When credentials like API keys and passwords are committed to repositories as ha
 
 {% data reusables.secret-scanning.what-is-scanned %}
 
+{% ifversion secret-scanning-actions-logs %}
+
+### Secrets detected in {% data variables.product.prodname_actions %} workflow logs
+
+> [!NOTE] 
+> Detection of secrets in {% data variables.product.prodname_actions %} workflow logs is in {% data variables.release-phases.public_preview %} and is subject to change.
+
+{% data variables.product.prodname_actions %} workflow log scanning is disabled by default. Enterprise owners can enable it for all repositories in their enterprise. For more information, see [AUTOTITLE](/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-security-and-analysis-for-your-enterprise#enforcing-a-policy-for-secret-scanning-in-github-actions-workflow-logs).
+
+Once enabled, {% data variables.product.github %} scans the logs of each new workflow run after the run completes, for repositories where {% data variables.product.prodname_secret_scanning %} is enabled. Logs from past workflow runs aren't scanned.
+
+For {% data variables.product.prodname_actions %} workflow logs, {% data variables.product.prodname_secret_scanning %} only detects provider patterns. It doesn't detect generic patterns, custom patterns, {% data variables.secret-scanning.ai-detected-secrets %}, or values that {% data variables.product.prodname_actions %} masks in the log.
+
+Alerts for secrets in {% data variables.product.prodname_actions %} workflow logs don't generate notifications during the {% data variables.release-phases.public_preview %}. To review these alerts, check the repository's {% data variables.product.prodname_secret_scanning %} alerts.
+
+A single alert may reference multiple locations if the same secret appeared across several workflow runs or jobs. For each location, the alert links to the workflow file where the secret originated and the log line where the secret was printed. The alert does not include an inline preview of the log content.
+
+{% endif %}
+
 ### {% data variables.product.prodname_secret_scanning_caps %} alerts and remediation
 
 When {% data variables.product.prodname_secret_scanning %} detects a credential leak, {% data variables.product.github %} generates an alert on your repository's **{% data variables.product.prodname_security_and_quality_tab %}** tab with details about the exposed credential.

content/code-security/how-tos/manage-security-alerts/manage-secret-scanning-alerts/resolving-alerts.md

@@ -24,6 +24,25 @@ Once a secret has been committed to a repository, you should consider the secret
 1. Review and update any services that use the old token. For {% data variables.product.github %} {% data variables.product.pat_generic %}s, delete the compromised token and create a new token. See [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).
 1. Depending on the secret provider, check your security logs for any unauthorized activity.
 
+{% ifversion secret-scanning-actions-logs %}
+
+### Fixing alerts for secrets in {% data variables.product.prodname_actions %} workflow logs
+
+> [!NOTE]
+> Detection of secrets in {% data variables.product.prodname_actions %} workflow logs is in {% data variables.release-phases.public_preview %} and is subject to change.
+
+When a secret is detected in a {% data variables.product.prodname_actions %} workflow log, follow these steps in order.
+
+1. Review the alert and linked job log to identify the credential and the source of the exposure. The secret may have been printed by the workflow, an action, or another dependency.
+1. Check whether the credential is still valid. {% ifversion fpt or ghec %}See [Checking a secret's validity](/code-security/tutorials/remediate-leaked-secrets/evaluating-alerts#checking-a-secrets-validity). {% endif %}If the credential is active or you cannot confirm its status, rotate or revoke it immediately using the secret provider's dashboard.
+1. Fix the source of the exposure. For example, update the workflow or dependency, remove hardcoded secrets, or store credentials as encrypted secrets. See [AUTOTITLE](/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions).
+1. If necessary, add `::add-mask::<value>` to redact the value from future log output.
+
+> [!WARNING]
+> Do not rerun the workflow until you have fixed the exposure source. Rerunning the workflow without addressing the root cause may re-expose the secret.
+
+{% endif %}
+
 {% ifversion secret-scanning-report-secret-github-pat %}
 
 ### Reporting a leaked secret in a private repository

content/copilot/concepts/agents/copilot-cli/about-custom-agents.md

@@ -31,7 +31,7 @@ In addition to the main {% data variables.product.prodname_copilot_short %} agen
 
 * **code-review** — Reviews code changes with an extremely high signal-to-noise ratio. This agent analyzes staged/unstaged changes and branch diffs, surfacing only issues that genuinely matter: bugs, security vulnerabilities, race conditions, memory leaks, and logic errors. It never comments on style or formatting. It will not make any changes to files.
 
-* **research** — This agent operates as a staff-level software engineer and research specialist. It provides exhaustive, meticulously researched answers about codebases, APIs, libraries, and software architecture. It uses {% data variables.product.github %} search/exploration tools, web fetch/search, and local tools. Unlike the other agents, the research agent can only be invoked by using the `/research` slash command. It cannot be automatically triggered by the main agent.
+* **research** — This agent operates as a staff-level software engineer and research specialist. It provides exhaustive, meticulously researched answers about codebases, APIs, libraries, and software architecture. It uses {% data variables.product.github %} search/exploration tools, web fetch/search, and local tools. You can invoke it explicitly using the `/research` slash command. The main agent can also delegate research work to it when appropriate.
 
 * **rubber-duck** — A constructive critic that gives {% data variables.product.prodname_copilot_short %} a second opinion on its own plans, code, and tests. It runs on a different model from the one driving your session, so it brings a complementary perspective. It is designed to review proposed changes, not to make file changes itself. For more information, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/rubber-duck).
 

content/copilot/concepts/agents/copilot-cli/autopilot.md

@@ -53,11 +53,11 @@ When entering autopilot mode, if you have not already granted {% data variables.
 
 ```text
 1. Enable all permissions (recommended)
-2. Continue with limited permissions
+2. Use Manual Approval for this session
 3. Cancel (Esc)
 ```
 
-You will get the best results from autopilot mode if you enable all permissions. If you choose to continue with limited permissions, {% data variables.product.prodname_copilot_short %} will automatically deny any tool requests that require approval, which may prevent it from completing certain tasks. You can change your mind later and grant full permissions, during an autopilot session, by using the `/allow-all` command (or its alias `/yolo`).
+You will get the best results from autopilot mode if you enable all permissions. If you choose manual approval, {% data variables.product.prodname_copilot_short %} will automatically deny any tool requests that require approval, which may prevent it from completing certain tasks. You can change your mind later and grant full permissions, during an autopilot session, by using the `/allow-all` command (or its alias `/yolo`).
 
 Before granting {% data variables.product.prodname_copilot_short %} wide-ranging permissions, consider using local sandboxing, or running the session in a cloud sandbox, to limit what {% data variables.product.prodname_copilot_short %} can access.
 
@@ -102,7 +102,7 @@ For example:
 
 * When the interactive session starts, if you're prompted to trust the files in the current folder, accept this option.
 * Press <kbd>Shift</kbd>+<kbd>Tab</kbd> to switch to plan mode, enter a prompt describing what you want to achieve, then work with {% data variables.product.prodname_copilot_short %} to create a detailed plan.
-* Once you have a plan that you are happy with, use the option that the CLI presents to "Accept plan and build on autopilot".
+* Once you have a plan that you are happy with, use the option that the CLI presents to "Accept plan and continue in Autopilot execution mode".
 * If you're prompted about permissions, choose the option to enable all permissions.
 * Leave {% data variables.product.prodname_copilot_short %} to implement the plan. You can check in on its progress periodically.
 

content/copilot/concepts/agents/copilot-cli/fleet.md

@@ -66,7 +66,7 @@ A typical workflow for using `/fleet` in autopilot mode might look like this:
 
 1. Press <kbd>Shift</kbd>+<kbd>Tab</kbd> to switch into plan mode and work with {% data variables.copilot.copilot_cli_short %} to create an implementation plan.
 1. Recognize that the completed plan contains multiple elements and looks like a good candidate for `/fleet`.
-1. Select the **Accept plan and build on autopilot + /fleet** option that's displayed when the plan is complete.
+1. Select the **Accept plan and continue in Autopilot execution mode + /fleet** option that's displayed when the plan is complete.
 
 For more information about autopilot mode, see [AUTOTITLE](/copilot/concepts/agents/copilot-cli/autopilot).