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
Copy file name to clipboardExpand all lines: docs/design.md
+14-4Lines changed: 14 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,10 +49,13 @@ repository:
49
49
(based on the `timeout` configured for the repository), it will cancel them.
50
50
- Reload user permissions from the Team API.
51
51
- Reload `rust-bors.toml` config for the repository from its main branch.
52
+
- Reload the mergeability status of open PRs from GitHub.
53
+
- Sync the status of PRs between the DB and GitHub.
54
+
- Run the merge queue.
52
55
53
56
## Concurrency
54
57
The bot is currently listening for GitHub webhooks concurrently, however it handles all commands serially, to avoid
55
-
race conditions. This limitation is expected to be lifted in the future.
58
+
race conditions. This limitation might be lifted in the future.
56
59
57
60
## Try builds
58
61
A try build means that you execute a specific CI job on a PR (without merging the PR), to test if the job passes C
@@ -202,6 +205,13 @@ With [homu](https://github.com/rust-lang/homu) (the old bors implementation), Gi
202
205
to use a "fake" job that marked the whole CI workflow as succeeded or failed, to signal to bors if it should consider
203
206
the workflow to be OK or not.
204
207
205
-
The new bors uses a different approach. It asks GitHub which [check suites](https://docs.github.com/en/rest/checks/suites)
206
-
are attached to a given commit, and then it waits until all of these check suites complete (or until a timeout is reached).
207
-
Thanks to this approach, there is no need to introduce fake CI jobs.
208
+
The new bors uses a different approach. In an earlier implementation, it used to ask GitHub which [check suites](https://docs.github.com/en/rest/checks/suites) were attached to a given commit, and then it waited until all of these check suites were completed (or until a timeout was reached). However, this was too "powerful" for rust-lang/rust, where we currently have only a single CI workflow per commit, and it was producing certain race conditions, where GitHub would send us a webhook that a check suite was completed, but when we then asked the GitHub API about the status of the check suite, it was still marked as pending.
209
+
210
+
To make the implementation more robust, it now behaves as follow:
211
+
- We listen for the workflow completed webhook.
212
+
- When it is received, we ask GitHub what are all the workflows attached to the workflow's check suite.
213
+
- If all of them are completed, we mark the build as finished.
214
+
215
+
Note that we explicitly do not read the "Check suite was completed" webhook, because it can actually be received *before* a webhook that tells us that the last workflow of that check suite was completed. If that happens, we could mark a build as completed without knowing the final conclusion of its workflows. That is not a big problem, but it would mean that we sometimes cannot post the real status of a workflow in the "build completed" bors comment on GitHub. So instead we just listen for the completed workflows.
216
+
217
+
In any case, with new bors there is no need to introduce fake conclusion CI jobs.
0 commit comments