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).
Copy file name to clipboardExpand all lines: content/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens.md
-154Lines changed: 0 additions & 154 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -117,160 +117,6 @@ For more information about best practices, see [AUTOTITLE](/rest/overview/keepin
117
117
118
118
If you selected an organization as the resource owner and the organization requires approval for {% data variables.product.pat_v2 %}s, then your token will be marked as `pending` until it is reviewed by an organization administrator. Your token will only be able to read public resources until it is approved. If you are an owner of the organization, your request is automatically approved. For more information, see [AUTOTITLE](/organizations/managing-programmatic-access-to-your-organization/reviewing-and-revoking-personal-access-tokens-in-your-organization).
119
119
120
-
### Pre-filling {% data variables.product.pat_v2 %} details using URL parameters
121
-
122
-
You can share templates for a {% data variables.product.pat_v2 %} via links. Storing token details this way makes it easier to automate workflows and improve your developer experience by directing users to token creation with relevant fields already completed.
123
-
124
-
Each supported field can be set using a specific query parameter. All parameters are optional and validated by the token generation form to ensure that the combinations of permissions and resource owner makes sense.
125
-
126
-
An example URL template is shown here, with line breaks for legibility:
Try the URL to create a token with `contents:read` and `metadata:read`, with the given name and description and an expiration date 45 days in the future. You'll see an error message indicating `Cannot find the specified resource owner: octodemo` because you're not a member of the `octodemo` organization.
138
-
139
-
Below are some example URLs that generate the tokens we see most often:
*[Update code and open a PR](https://github.com/settings/personal-access-tokens/new?name=Core-loop+token&description=Write%20code%20and%20push%20it%20to%20main%21%20Includes%20permission%20to%20edit%20workflow%20files%20for%20Actions%20-%20remove%20%60workflows%3Awrite%60%20if%20you%20don%27t%20need%20to%20do%20that&contents=write&pull_requests=write&workflows=write)
145
-
*[Manage Copilot licenses in an organization](https://github.com/settings/personal-access-tokens/new?name=Core-loop+token&description=Enable%20or%20disable%20copilot%20access%20for%20users%20with%20the%20Seat%20Management%20APIs%3A%20https%3A%2F%2Fdocs.github.com%2Frest%2Fcopilot%2Fcopilot-user-management%0ABe%20sure%20to%20select%20an%20organization%20for%20your%20resource%20owner%20below%21&organization_copilot_seat_management=write)<!-- markdownlint-disable-line search-replace Custom rule -->
|`description`| string |`Used+for+deployments`| ≤ 1024 chars, URL-encoded | Pre-fills the description for the token. |
156
-
|`target_name`| string |`octodemo`| User or organization slug | Sets the token's resource target. This is the owner of the repositories that the token will be able to access. If not provided, defaults to the current user's account. |
157
-
|`expires_in`| integer|`30` or `none`| Integer between 1 and 366, or `none`| Days until expiration or `none` for non-expiring. If not provided, the default is 30 days, or less if the target has a token lifetime policy set. |
158
-
|`<permission>`| string |`contents=read`| A series of permission and access levels. | The permissions the token should have. Permissions can be set to `read`, `write`, or `admin`, but not every permission supports each of those levels. |
159
-
160
-
#### Permissions
161
-
162
-
Each supported permission is set using its name as a query parameter, with the value specifying the desired access level. Valid access levels are `read`, `write`, and `admin`. Some permissions only support `read`, some only support `write`, and only a few have `admin`. Use as many permissions as needed, in the form `&contents=read&pull_requests=write&...`.
163
-
164
-
You do not need to include both `read` and `write` for a permission in your URL—`write` always includes `read`, and `admin` always includes `write`.
165
-
166
-
##### Account Permissions
167
-
168
-
Account permissions are only used when the current user is set as the resource owner.
169
-
170
-
| Parameter name | Display name | Access levels |
171
-
|---|---|---|
172
-
|`blocking`| Block another user |`read`, `write`|
173
-
|`codespaces_user_secrets`| Codespaces user secrets |`read`, `write`|
> The `copilot_requests` permission enables making {% data variables.product.prodname_copilot_short %} requests for the given user, which count towards the user's premium request allowance or are charged to overage billing if the allowance is exceeded. For more information about {% data variables.product.prodname_copilot_short %} requests and billing, see [AUTOTITLE](/copilot/concepts/billing/copilot-requests).
197
-
198
-
{% endif %}
199
-
##### Repository Permissions
200
-
201
-
Repository permissions work for both user and organization resource owners.
intro: Get started content provides the minimal essential information to use a product or feature.
4
+
versions:
5
+
fpt: '*'
6
+
ghec: '*'
7
+
ghes: '*'
8
+
category:
9
+
- Follow the style guide and content model
10
+
---
11
+
12
+
Get started content provides an entry point into using GitHub products and features. This section should contain only the minimum essential information a user needs before they move on to concepts and how-tos. We do this to be concise, and also so it doesn't seem complicated just to get started with a feature.
13
+
14
+
## Get started considerations
15
+
16
+
Get started is a set of articles which should be easy and fast to scan. It should contain fewer than 5 articles, and ideally only two:
17
+
* Quickstart
18
+
* About [PRODUCT] (or “What is [PRODUCT]”)
19
+
20
+
The one exception to this may be with available plans and billing information, where such information is required to use the product or feature.
21
+
22
+
For more information on quickstart content, see [AUTOTITLE](/contributing/style-guide-and-content-model/quickstart-content-type).
23
+
24
+
In particular, articles with this information do not belong in Get started:
25
+
* Articles that fall under the how-to content type.
26
+
* Set up or sign up steps: these are also how-tos. They document how to do something in the UI.
27
+
* Content that is useful for getting started with a particular feature but not the whole product area. This kind of content more properly belongs in Concepts.
28
+
* Best practices, generally. Users new to a feature lack the context necessary to make the most of these.
0 commit comments