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
- Checks if a PR branch needs to update with the default branch prior to merging (great for monorepos!)
85
-
- If this check succeeds for a PR, the PR is safe to merge right away!
86
-
- If this check fails for a PR, the PR must either merge in the default branch or rebase onto the default branch.
84
+
- Checks if a PR branch needs to update with the default branch prior to merging (great for monorepos!)
85
+
- If this check succeeds for a PR, the PR is safe to merge right away!
86
+
- If this check fails for a PR, the PR must either merge in the default branch or rebase onto the default branch.
87
87
88
88
"Merge safety"is defined as a PR's branch being up to date with all files that could impact the validity of the PR checks that run.
89
89
This merge safety check is designed to be a smarter alternative to GitHub's "[require branches to be up to date before merging](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging)"
@@ -110,62 +110,62 @@ to ship code in quick succession!
110
110
111
111
This workflow should be run on both `pull_request` and `push` events:
112
112
113
-
- On `pull_request` events, this serves as a PR check
114
-
- On `push` events, this effectively re-runs this PR check for all open PRs and sets a commit status according to the result
113
+
- On `pull_request` events, this serves as a PR check
114
+
- On `push` events, this effectively re-runs this PR check for all open PRs and sets a commit status according to the result
115
115
116
116
The following parameters can be used for additional control over when it is safe to merge a PR:
117
117
118
-
- `paths`: These are the file paths to all of a repo's projects (usually paths to standalone packages)
119
-
- This is useful for monorepos with multiple projects which are decoupled from each other but are affected by global dependencies.
120
-
- `ignore_globs`: These are glob patterns that, if out of date on a PR, will not prevent merge
121
-
- example: `ignore_globs: **.md`
122
-
- `override_filter_paths`: These are the file paths that, if out of date on a PR, will prevent merge no matter what files the PR is changing
- Creates a Project card into your GitHub Project repository by providing a `project_name` and `project_destination_column_name` in which the card should be created.
137
-
- If `note` is provided, it will add that information into the card. If it is not provided, it will use the PR information details to populate it.
138
-
- Useful when opening a pull request and want to track its information details into a GitHub Project.
136
+
- Creates a Project card into your GitHub Project repository by providing a `project_name` and `project_destination_column_name` in which the card should be created.
137
+
- If `note` is provided, it will add that information into the card. If it is not provided, it will use the PR information details to populate it.
138
+
- Useful when opening a pull request and want to track its information details into a GitHub Project.
- Deletes a Github [deployment](https://docs.github.com/en/rest/reference/repos#deployments) and [environment](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#about-environments)
154
+
- Deletes a Github [deployment](https://docs.github.com/en/rest/reference/repos#deployments) and [environment](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#about-environments)
- Returns a job matrix JSON for dynamically running workflows only for changed file paths
167
-
- Can be used to parallelize similar jobs, which can be useful in a monorepo environment. More information on matrix strategies can be found [here](https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)
168
-
- In this example, a multi-package repo splits its builds dynamically based on which packages are modified in the pull request. These builds run in parallel, and the final `build-status` job is used to determine the overall success/failure result, contingent on all of the individual `build` jobs passing. The helper returns a JSON object of this format:
166
+
- Returns a job matrix JSON for dynamically running workflows only for changed file paths
167
+
- Can be used to parallelize similar jobs, which can be useful in a monorepo environment. More information on matrix strategies can be found [here](https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)
168
+
- In this example, a multi-package repo splits its builds dynamically based on which packages are modified in the pull request. These builds run in parallel, and the final `build-status` job is used to determine the overall success/failure result, contingent on all of the individual `build` jobs passing. The helper returns a JSON object of this format:
169
169
170
170
```json
171
171
{
@@ -175,91 +175,91 @@ The following parameters can be used for additional control over when it is safe
175
175
176
176
Additionally, the following parameters can be used for additional control over the resulting matrix:
177
177
178
-
- `override_filter_paths`defines paths that, if modified, will override the filter and return a matrix including all packages
- Creates a new in-progress Github "deployment" for a commit. More information on Github deployment events can be found [here](https://docs.github.com/en/rest/reference/repos#deployments)
190
+
- Creates a new in-progress Github "deployment" for a commit. More information on Github deployment events can be found [here](https://docs.github.com/en/rest/reference/repos#deployments)
- Adding the `READY TO MERGE` label to a PR will add the PR to the "merge queue", represented by a `QUEUED FOR MERGE #X` label. Removing `READY TO MERGE` will remove this label and thus remove the PR from the queue.
210
-
- If a PR is first in the queue, the `QUEUE CHECKER` commit status will be set to `success`, and it will be `pending` otherwise. Github's [branch protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule) can be used to ensure this requirement is met prior to merging.
211
-
- Merging a PR will update the positions of all PRs in the queue.
212
-
- Adding the `JUMP THE QUEUE` label to a PR will make that PR first in the queue immediately.
213
-
- When a PR is merged, it automatically updates the first-queued PR with the default branch.
214
-
- You can also pass `login` and `slack_webhook_url` to notify the PR author when they are in the 1st position of the merge queue.
215
-
- Passing `skip_auto_merge: true` changes the default behaviour of automatically enabling auto-merge for PRs from the merge queue. In such case auto-merging should be enabled manually on individual PRs. It can be useful to avoid unattended deployments in case of CICD pipelines which are not fully prepared for continuous deployment.
208
+
- Manages a queue for PRs as follows:
209
+
- Adding the `READY TO MERGE` label to a PR will add the PR to the "merge queue", represented by a `QUEUED FOR MERGE #X` label. Removing `READY TO MERGE` will remove this label and thus remove the PR from the queue.
210
+
- If a PR is first in the queue, the `QUEUE CHECKER` commit status will be set to `success`, and it will be `pending` otherwise. Github's [branch protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule) can be used to ensure this requirement is met prior to merging.
211
+
- Merging a PR will update the positions of all PRs in the queue.
212
+
- Adding the `JUMP THE QUEUE` label to a PR will make that PR first in the queue immediately.
213
+
- When a PR is merged, it automatically updates the first-queued PR with the default branch.
214
+
- You can also pass `login` and `slack_webhook_url` to notify the PR author when they are in the 1st position of the merge queue.
215
+
- Passing `skip_auto_merge: true` changes the default behaviour of automatically enabling auto-merge for PRs from the merge queue. In such case auto-merging should be enabled manually on individual PRs. It can be useful to avoid unattended deployments in case of CICD pipelines which are not fully prepared for continuous deployment.
- Removes a PR from the merge queue if it has a stale failing status check. A PR check is considered stale if it is older than the provided number of `seconds`.
236
+
- Removes a PR from the merge queue if it has a stale failing status check. A PR check is considered stale if it is older than the provided number of `seconds`.
237
237
238
238
### [reopen-pr](.github/workflows/reopen-pr.yml)
239
239
240
-
- Reopens a pull request in your current repo or in another repo.
240
+
- Reopens a pull request in your current repo or in another repo.
- Reruns all of the latest workflow checks on a pull request (helpful if they were cancelled for some reason, either manually or due to rate limiting, for example).
244
+
- Reruns all of the latest workflow checks on a pull request (helpful if they were cancelled for some reason, either manually or due to rate limiting, for example).
- Determines whether the pipeline is clear for a PR. This means it will set the "pipeline" commit status to `pending` if there is an in-progress production deployment for the repo, and `success` otherwise.
257
+
- Determines whether the pipeline is clear for a PR. This means it will set the "pipeline" commit status to `pending` if there is an in-progress production deployment for the repo, and `success` otherwise.
0 commit comments