Compare changes
Choose two branches to see what one has that the other does not, then open a pull request for it.
1 commit
2 files+18−30/2 viewed
| 29 | 29 | ||
| 30 | 30 | | On GitHub | On g1t | | |
| 31 | 31 | | --- | --- | | |
| 32 | − | | `on:` `push` (branches, tags, paths), `pull_request`, `pull_request_target`, `issues`, `issue_comment`, `pull_request_review`, `schedule`, `workflow_dispatch`, `workflow_run` | The same, from g1t's own pushes, pull requests, issues and comments. | | |
| 32 | + | | `on:` `push` (branches, tags, paths), `pull_request`, `pull_request_target`, `issues`, `issue_comment`, `pull_request_review`, `schedule`, `workflow_dispatch`, `workflow_run`, `merge_group` | The same, from g1t's own pushes, pull requests, issues, comments and [merge queue](/guides/merge-queue/). | | |
| 33 | 33 | | `jobs`, `needs`, `if`, `outputs`, `env`, `defaults`, `timeout-minutes`, `continue-on-error` | The same. | | |
| 34 | 34 | | `strategy.matrix` with `include` and `exclude`, `fail-fast`, `max-parallel`, a matrix from `fromJSON(needs.…)` | The same. | | |
| 35 | 35 | | `concurrency` with `cancel-in-progress` | The same. | | |
| 94 | 94 | - While a workflow runs, the pull request waits for it before merging. | |
| 95 | 95 | - When one fails, merging is refused, as for failed acceptance checks. | |
| 96 | 96 | Where the repository allows ignoring checks, a member can merge anyway. | |
| 97 | + | - In a repository that merges through the [merge queue](/guides/merge-queue/), | |
| 98 | + | workflows with `on: merge_group` run on each combined state the queue | |
| 99 | + | builds, as on GitHub, and the state lands only if they pass. | |
| 97 | 100 | - A pull request a **g1t agent** is working on goes back to the agent | |
| 98 | 101 | when a workflow fails. The agent reads the run and its logs with the | |
| 99 | 102 | same tools you have, fixes the cause, and pushes; the workflows run |
| 75 | 75 | So a change that breaks something that landed before it is caught here, | |
| 76 | 76 | even when it merges without a conflict and its own checks pass. | |
| 77 | 77 | ||
| 78 | + | Once those pass, the repository's [GitHub Actions](/guides/actions/) | |
| 79 | + | workflows that run `on: merge_group` run on the state too, with the same | |
| 80 | + | `merge_group` event GitHub sends, on the branch `g1t-queue/<entry>`. The | |
| 81 | + | entry waits for them, and lands only if they pass: | |
| 82 | + | ||
| 83 | + | ```yaml | |
| 84 | + | on: | |
| 85 | + | pull_request: | |
| 86 | + | merge_group: | |
| 87 | + | ``` | |
| 88 | + | ||
| 78 | 89 | A contract check that fails is run again on `main` alone. If it fails there | |
| 79 | 90 | too, it was broken already: it is marked as passing with a note, "already | |
| 80 | 91 | failing on the default branch; not held against this", and does not hold | |
| 96 | 107 | ||
| 97 | 108 | ## When an entry fails | |
| 98 | 109 | ||
| 99 | − | An entry fails when its checks fail in the combined state, when it does not | |
| 100 | − | merge cleanly with what is ahead of it, or when the state cannot be built. | |
| 110 | + | An entry fails when its checks or its `merge_group` workflows fail in the | |
| 111 | + | combined state, when it does not merge cleanly with what is ahead of it, or | |
| 112 | + | when the state cannot be built. | |
| 101 | 113 | It leaves the queue, and: | |
| 102 | 114 | ||
| 103 | 115 | 1. Its pull request gets a failed check run. Each command is named with the |