Repo sync

config/moda/deployment.yaml

@@ -3,6 +3,9 @@
 environments:
   - name: production
     require_pipeline: true
+    # Bumped from default 10m because pod scheduling occasionally pushes
+    # rollouts past the timeout even though the deploy itself succeeds.
+    timeout: 1200
     cluster_selector:
       profile: general
       region: iad
@@ -201,13 +204,13 @@ pipelines:
   production_rollout:
     thread_notifications: true
     notify_users_via_dm: false
-    timeout: 1200
+    timeout: 1800
     stages:
       - name: full_production
         kind: deployment
         config:
           environment: production
-          timeout: 1200
+          timeout: 1800
 
 notifications:
   slack_channels:

content/actions/concepts/security/github_token.md

@@ -29,6 +29,11 @@ The token is also available in the `github.token` context. For more information,
 
 {% data reusables.actions.actions-do-not-trigger-workflows %}
 
+{% ifversion actions-github-token-pull-request-approval %}
+> [!NOTE]
+> If you need workflow runs from workflow-created pull requests to execute without requiring approval, use a {% data variables.product.prodname_github_app %} installation access token or a {% data variables.product.pat_generic %} instead of `GITHUB_TOKEN` when creating or updating the pull request.
+{% endif %}
+
 {% data reusables.actions.actions-do-not-trigger-pages-rebuilds %}
 
 ## Next steps

content/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow.md

@@ -25,7 +25,7 @@ To learn more about workflows and triggering workflows, see [AUTOTITLE](/actions
 
 {% data reusables.actions.actions-do-not-trigger-workflows %} For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication).
 
-If you do want to trigger a workflow from within a workflow run, you can use a {% data variables.product.prodname_github_app %} installation access token or a {% data variables.product.pat_generic %} instead of `GITHUB_TOKEN` to trigger events that require a token.
+If you do want to trigger a workflow from within a workflow run, you can use a {% data variables.product.prodname_github_app %} installation access token or a {% data variables.product.pat_generic %} instead of `GITHUB_TOKEN` to trigger events that require a token.{% ifversion actions-github-token-pull-request-approval %} Using one of these alternatives also lets `pull_request` workflows run automatically (without the approval prompt described above) when the pull request is created or updated by automation.{% endif %}
 
 If you use a {% data variables.product.prodname_github_app %}, you'll need to create a {% data variables.product.prodname_github_app %} and store the app ID and private key as secrets. For more information, see [AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow). If you use a {% data variables.product.pat_generic %}, you'll need to create a {% data variables.product.pat_generic %} and store it as a secret. For more information about creating a {% data variables.product.pat_generic %}, see [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token). For more information about storing secrets, see [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions).
 

content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md

@@ -510,7 +510,8 @@ on:
 > [!NOTE]
 > * {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request). By default, a workflow only runs when a `pull_request` event's activity type is `opened`, `synchronize`, or `reopened`. To trigger workflows by different activity types, use the `types` keyword. For more information, see [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes).
 > * Workflows will not run on `pull_request` activity if the pull request has a merge conflict. The merge conflict must be resolved first. Conversely, workflows with the `pull_request_target` event will run even if the pull request has a merge conflict. Before using the `pull_request_target` trigger, you should be aware of the security risks. For more information, see [`pull_request_target`](#pull_request_target).
-> * The `pull_request` webhook event payload is empty for merged pull requests and pull requests that come from forked repositories.
+> * The `pull_request` webhook event payload is empty for merged pull requests and pull requests that come from forked repositories.{% ifversion actions-github-token-pull-request-approval %}
+> * When a pull request is created or updated by a workflow using `GITHUB_TOKEN`, `pull_request` events with the `opened`, `synchronize`, or `reopened` activity types create workflow runs that require approval. A user with write access to the repository can approve these runs from the pull request page. With the exception of `workflow_dispatch` and `repository_dispatch`, other `GITHUB_TOKEN`-triggered events do not create workflow runs at all.{% endif %}
 > * The value of `GITHUB_REF` varies for a closed pull request depending on whether the pull request has been merged or not. If a pull request was closed but not merged, it will be `refs/pull/PULL_REQUEST_NUMBER/merge`. If a pull request was closed as a result of being merged, it will be the fully qualified `ref` of the branch it was merged into, for example `/refs/heads/main`.
 
 Runs your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated. For activity related to pull request reviews, pull request review comments, or pull request comments, use the [`pull_request_review`](#pull_request_review), [`pull_request_review_comment`](#pull_request_review_comment), or [`issue_comment`](#issue_comment) events instead. For information about the pull request APIs, see [AUTOTITLE](/graphql/reference/objects#pullrequest) in the GraphQL API documentation or [AUTOTITLE](/rest/pulls).

content/actions/tutorials/create-actions/create-a-composite-action.md

@@ -247,11 +247,3 @@ jobs:
         env:
           RANDOM_NUMBER: {% raw %}${{ steps.foo.outputs.random-number }}{% endraw %}
 ```
-
-## Example composite actions on {% data variables.product.github %}
-
-You can find many examples of composite actions on {% data variables.product.github %}.
-
-* [microsoft/action-python](https://github.com/microsoft/action-python)
-* [microsoft/gpt-review](https://github.com/microsoft/gpt-review)
-* [tailscale/github-action](https://github.com/tailscale/github-action)

content/billing/reference/product-and-sku-names.md

@@ -31,64 +31,41 @@ For **SkuPricing** budgets or to query usage by SKU, use one of the following va
 
 <!-- markdownlint-disable GHD046 -->
 
-* `actions_beta_classroom_repository` - Actions beta classroom repository
-* `actions_beta_custom_runner_azure` - Actions beta custom runner (Azure)
-* `actions_beta_macos_xl_runner` - Actions beta macOS XL runner
-* `actions_beta_public_repository` - Actions beta public repository
-* `actions_beta_self_hosted_runner` - Actions beta self-hosted runner
 * `actions_cache_storage` - Actions cache storage
 * `actions_custom_image_storage` - Actions custom image storage
 * `actions_linux` - Actions Linux runners
-* `actions_linux_16_core_perf` - Actions Linux 16-core performance
-* `actions_linux_20_core_mem` - Actions Linux 20-core memory
 * `actions_linux_2_core_advanced` - Actions Linux 2-core advanced
 * `actions_linux_2_core_arm` - Actions Linux 2-core ARM
 * `actions_linux_32_core` - Actions Linux 32-core
 * `actions_linux_32_core_arm` - Actions Linux 32-core ARM
-* `actions_linux_32_core_stor` - Actions Linux 32-core storage
 * `actions_linux_4_core` - Actions Linux 4-core
-* `actions_linux_4_core_advanced` - Actions Linux 4-core advanced
+* `actions_linux_4_core_arm` - Actions Linux 4-core ARM
 * `actions_linux_4_core_gpu` - Actions Linux 4-core GPU
 * `actions_linux_64_core` - Actions Linux 64-core
 * `actions_linux_64_core_arm` - Actions Linux 64-core ARM
 * `actions_linux_8_core` - Actions Linux 8-core
 * `actions_linux_8_core_arm` - Actions Linux 8-core ARM
-* `actions_linux_8_core_stor` - Actions Linux 8-core storage
 * `actions_linux_96_core` - Actions Linux 96-core
-* `actions_linux_a100_24_core_gpu` - Actions Linux A100 24-core GPU
-* `actions_linux_a10_36_core_gpu` - Actions Linux A10 36-core GPU
 * `actions_linux_arm` - Actions Linux ARM
 * `actions_linux_slim` - Actions Linux slim
 * `actions_macos` - Actions macOS runners
-* `actions_macos_12_core` - Actions macOS 12-core
-* `actions_macos_8_core` - Actions macOS 8-core
 * `actions_macos_l` - Actions macOS large
 * `actions_macos_xl` - Actions macOS XL
-* `actions_self_hosted_linux` - Actions self-hosted Linux
-* `actions_self_hosted_macos` - Actions self-hosted macOS
-* `actions_self_hosted_unknown` - Actions self-hosted unknown
-* `actions_self_hosted_windows` - Actions self-hosted Windows
 * `actions_storage` - Actions storage
-* `actions_unknown` - Actions unknown
 * `actions_windows` - Actions Windows runners
 * `actions_windows_16_core` - Actions Windows 16-core
-* `actions_windows_176_core_perf` - Actions Windows 176-core performance
 * `actions_windows_2_core` - Actions Windows 2-core
 * `actions_windows_2_core_advanced` - Actions Windows 2-core advanced
 * `actions_windows_2_core_arm` - Actions Windows 2-core ARM
+* `actions_windows_4_core_arm` - Actions Windows 4-core ARM
 * `actions_windows_32_core` - Actions Windows 32-core
 * `actions_windows_32_core_arm` - Actions Windows 32-core ARM
-* `actions_windows_32_core_stor` - Actions Windows 32-core storage
 * `actions_windows_4_core` - Actions Windows 4-core
 * `actions_windows_4_core_gpu` - Actions Windows 4-core GPU
 * `actions_windows_64_core` - Actions Windows 64-core
 * `actions_windows_64_core_arm` - Actions Windows 64-core ARM
 * `actions_windows_8_core` - Actions Windows 8-core
 * `actions_windows_8_core_arm` - Actions Windows 8-core ARM
-* `actions_windows_8_core_mem` - Actions Windows 8-core memory
-* `actions_windows_8_core_stor` - Actions Windows 8-core storage
-* `actions_windows_a100_24_core_gpu` - Actions Windows A100 24-core GPU
-* `actions_windows_a10_36_core_gpu` - Actions Windows A10 36-core GPU
 * `actions_windows_arm` - Actions Windows ARM
 
  <!-- markdownlint-enable GHD046 -->

content/copilot/how-tos/troubleshoot-copilot/troubleshoot-common-issues.md

@@ -71,7 +71,7 @@ Most people see rate limiting for select models, due to limited capacity.
 
 Service-level request rate limits ensure high service quality for all {% data variables.product.prodname_copilot_short %}  users and should not affect typical or even deeply engaged {% data variables.product.prodname_copilot_short %} usage. We are aware of some use cases that are affected by it. {% data variables.product.github %} is iterating on {% data variables.product.prodname_copilot_short %}’s rate-limiting heuristics to ensure it doesn’t block legitimate use cases.
 
-In the case you are rate limited, the error message will contain the suggested time to retry for a successful request. Consider [alternative actions](/copilot/concepts/rate-limits#what-to-do-if-you-are-rate-limited) to continue using {% data variables.product.prodname_copilot_short %} while your limit is reset.
+If you are rate limited, the error message will contain the suggested retry time for a successful request. For more information about alternative actions you can take while your limit resets, see [AUTOTITLE](/copilot/concepts/usage-limits#what-to-do-if-you-hit-a-limit).
 
 In case you experience repeated rate limiting in {% data variables.product.prodname_copilot_short %} contact {% data variables.contact.contact_support_page %}.
 

content/organizations/managing-organization-settings/index.md

@@ -40,6 +40,7 @@ children:
   - /managing-the-display-of-member-names-in-your-organization
   - /managing-updates-from-accounts-your-organization-sponsors
   - /managing-the-publication-of-github-pages-sites-for-your-organization
+  - /managing-commit-comments-for-your-organization
   - /archiving-an-organization
   - /deleting-an-organization-account
   - /converting-an-organization-into-a-user

content/organizations/managing-organization-settings/managing-commit-comments-for-your-organization.md

@@ -0,0 +1,38 @@
+---
+title: Managing commit comments for your organization
+intro: 'Organization owners can allow or disallow commit comments by default for repositories in their organization.'
+permissions: Organization owners
+versions:
+  fpt: '*'
+  ghes: '>= 3.22'
+  ghec: '*'
+shortTitle: Manage commit comments
+category:
+  - Set repository policies
+---
+
+## About commit comments
+
+Commit comments are comments people add directly to a commit outside of a pull request. Disallowing commit comments can help organizations reduce noise and maintain cleaner commit histories, especially if commit comments are not part of your development workflow.
+
+It is possible to allow or disallow commit comments at a repository level. Organization owners can configure the default setting for commit comments for all repositories in an organization.
+
+## What happens when commit comments are disabled?
+
+When you disable commit comments for your organization:
+
+* People cannot create new commit comments.
+* Existing commit comments remain visible.
+* Repository administrators can override the setting in their repository's settings.
+
+## Managing the default setting for commit comments in your organization's repositories
+
+{% data reusables.profile.access_org %}
+{% data reusables.profile.org_settings %}
+1. In the "Code, planning, and automation" section of the sidebar, select **{% octicon "repo" aria-hidden="true" aria-label="repo" %} Repository**, then click **General**.
+1. Under "Commits", select or deselect **Allow comments on individual commits**.
+
+
+## Further reading
+
+* [AUTOTITLE](/communities/moderating-comments-and-conversations/managing-disruptive-comments)

data/features/actions-github-token-pull-request-approval.yml

@@ -0,0 +1,7 @@
+# Approval-required workflow runs for pull requests created or updated by
+# workflows using GITHUB_TOKEN. Implementation feature flag:
+# `actions_requires_approval_for_actions_bot_prs`.
+versions:
+  fpt: '*'
+  ghec: '*'
+  # ghes: '>=3.XX' # Uncomment when this ships to GHES (currently rolling out on dotcom)

data/features/vulnerability-alerts-permission.yml

@@ -0,0 +1,6 @@
+# Vulnerability alerts permission for GITHUB_TOKEN
+# GHES support will be added when the feature ships to GHES
+versions:
+  fpt: '*'
+  ghec: '*'
+  # ghes: '>=3.XX' # Uncomment when vulnerability-alerts permission ships to GHES

data/reusables/actions/actions-do-not-trigger-workflows.md

@@ -1 +1,6 @@
-When you use the repository's `GITHUB_TOKEN` to perform tasks, events triggered by the `GITHUB_TOKEN`, with the exception of `workflow_dispatch` and `repository_dispatch`, will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's `GITHUB_TOKEN`, a new workflow will not run even when the repository contains a workflow configured to run when `push` events occur.
+When you use the repository's `GITHUB_TOKEN` to perform tasks, events triggered by the `GITHUB_TOKEN` will not create a new workflow run, with the following exceptions:
+
+* `workflow_dispatch` and `repository_dispatch` events always create workflow runs.{% ifversion actions-github-token-pull-request-approval %}
+* `pull_request` events with the `opened`, `synchronize`, or `reopened` activity types: when a workflow using `GITHUB_TOKEN` creates or updates a pull request, the resulting `pull_request` event creates workflow runs in an **approval-required** state. The pull request displays a banner in the merge box, and a user with write access to the repository can start the runs by selecting **Approve workflows to run**. Other `pull_request` activity types (such as `labeled`, `edited`, or `closed`) do not create workflow runs. This prevents recursive workflow runs while still allowing CI workflows to run on pull requests created by automation. For more information about approving workflow runs, see [AUTOTITLE](/actions/how-tos/manage-workflow-runs/approve-runs-from-forks).{% endif %}
+
+For all other events, this behavior prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's `GITHUB_TOKEN`, a new workflow will not run even when the repository contains a workflow configured to run when `push` events occur.

data/reusables/actions/github-token-available-permissions.md

@@ -17,7 +17,8 @@ permissions:
   pull-requests: read|write|none{% ifversion projects-v1 %}
   repository-projects: read|write|none{% endif %}
   security-events: read|write|none
-  statuses: read|write|none
+  statuses: read|write|none{% ifversion vulnerability-alerts-permission %}
+  vulnerability-alerts: read|none{% endif %}
 ```
 
 If you specify the access for any of these permissions, all of those that are not specified are set to `none`.