You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> 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.
35
+
{% endif %}
36
+
32
37
{% data reusables.actions.actions-do-not-trigger-pages-rebuilds %}
Copy file name to clipboardExpand all lines: content/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,7 +25,7 @@ To learn more about workflows and triggering workflows, see [AUTOTITLE](/actions
25
25
26
26
{% data reusables.actions.actions-do-not-trigger-workflows %} For more information, see [AUTOTITLE](/actions/security-guides/automatic-token-authentication).
27
27
28
-
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.
28
+
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 %}
29
29
30
30
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).
Copy file name to clipboardExpand all lines: content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -510,7 +510,8 @@ on:
510
510
> [!NOTE]
511
511
> * {% 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).
512
512
> * 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).
513
-
> * The `pull_request` webhook event payload is empty for merged pull requests and pull requests that come from forked repositories.
513
+
> * 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 %}
514
+
> * 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 %}
514
515
> * 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`.
515
516
516
517
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).
title: Managing commit comments for your organization
3
+
intro: 'Organization owners can allow or disallow commit comments by default for repositories in their organization.'
4
+
permissions: Organization owners
5
+
versions:
6
+
fpt: '*'
7
+
ghes: '>= 3.22'
8
+
ghec: '*'
9
+
shortTitle: Manage commit comments
10
+
category:
11
+
- Set repository policies
12
+
---
13
+
14
+
## About commit comments
15
+
16
+
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.
17
+
18
+
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.
19
+
20
+
## What happens when commit comments are disabled?
21
+
22
+
When you disable commit comments for your organization:
23
+
24
+
* People cannot create new commit comments.
25
+
* Existing commit comments remain visible.
26
+
* Repository administrators can override the setting in their repository's settings.
27
+
28
+
## Managing the default setting for commit comments in your organization's repositories
29
+
30
+
{% data reusables.profile.access_org %}
31
+
{% data reusables.profile.org_settings %}
32
+
1. In the "Code, planning, and automation" section of the sidebar, select **{% octicon "repo" aria-hidden="true" aria-label="repo" %} Repository**, then click **General**.
33
+
1. Under "Commits", select or deselect **Allow comments on individual commits**.
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.
1
+
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:
*`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 %}
5
+
6
+
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.
0 commit comments