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
This document describes how we might use the merge queue feature in spack CI.
3
+
This document describes how we might use the merge queue feature in spack CI. There are two ways we can consider taking advantage of the merge queue functionality for testing in spack, using the existing `gh-gl-sync` script, or moving to a fully event-driven system using spackbot or some other event handling system.
4
+
5
+
## Using the `gh-gl-sync` cron job
6
+
7
+
8
+
9
+
## Using an event-based approach
10
+
11
+
The events we receive from github are documented in the [NOTES.md](./NOTES.md), with links to actual example events received.
Things behaved differently once the repo was made public (github would enforce the branch protections) and once spackbot-test had posted status on a commit. With the posted status, we can choose it in the branch protection settings as a required status, and then github waits for that status (using yellow color to indicate pending status, "merge when ready" button is black, not green, though it seems I could still click it).
145
+
146
+
When these two things are set, we started getting a new event from github (`merge_group / checks_requested`, see [example](./events/merge_group_checks_requested.json)).
147
+
148
+
Also, at this point, we enabled a new PR comment message:
149
+
150
+
```
151
+
@spackbot-test check <success|failure> <sha>
152
+
```
153
+
154
+
which allows to pass or fail any commit at a time of our choosing. This is convenient to make sure we had time to inspect the state of the repo by fetching branches and looking at logs, examing the github ui, etc. We can also choose to pass/fail items in the queue in a specific order to see how github responds. Here is an experiment we conducted once we had the capabilities outlined in this section.
155
+
156
+
With everything above in place, I posted a success status on the latest commit of an open PR, which turned the "merge when ready" button green, so I pushed it and confirmed.
157
+
158
+
- This triggered a new type of event from github, as mentioned above, a `merge_group` event with action set to `checks_requested`.
159
+
_ the event object had a key `merge_group` with fields including `base_sha` as described in this [doc](https://github.blog/changelog/2022-08-18-merge-group-webhook-event-and-github-actions-workflow-trigger). This `base_sha` was `fe863b8ab7a820b363bfdccf002ae1dc7925a598`.
160
+
161
+
- Fetching from the repo at this point resulted in a new branch `gh-readonly-queue/main/pr-6-1b1aaaec8784d524335dc225a4e21030941424a5`:
Merge pull request #6 from scottwittenburg/add-ci-proposal-doc
170
+
171
+
Add a CI document describing how we can use merge queue
172
+
173
+
- Here is the order of events received after clicking "Merge when ready":
174
+
175
+
- merge_queue_entry / created
176
+
- pull_request / enqueued
177
+
- merge_group / checks_requested
178
+
179
+
- Once I asked @spackbot-test to post succes on `fe863b8ab7a820b363bfdccf002ae1dc7925a598`, the PR was automatically merged. This corresponded with receiving the following events:
180
+
181
+
- pull_request / dequeued
182
+
- pull_request / closed
183
+
- merge_queue_entry / deleted
184
+
185
+
### Experimenting with several PRs in the queue
186
+
187
+
For this experiment, we create three PRs (#7, #8, and #9) with passed tests (thanks to @spackbot-test check success <sha>) ready to add to merge queue. Because we had set the merge group size to `small` (corresponding to 2 PRs per group), we didn't expect to be able to add all three PRs to the merge queue, but it was allowed anyway.
188
+
189
+
The three PRs in were in the queue in the following order, from highest/first to lowest/last:
190
+
191
+
1. PR #7 (GH branch included only #7 merged into base)
192
+
2. PR #8 (GH branch included the merge commit from (1), above, as its base)
193
+
3. PR #9 (GH branch included the merge commit from (2), above, as its base, so it included changes from #7 and #8)
194
+
195
+
First test was to ask @spackbot-test to fail the middle one in the queue (2), and after 5-10 min, nothing had been removed from the queue. While that is not what this [doc](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) says will happend, it may just be the doc ommitted to mention action is only taken when status is reported on the first item in the queue.
196
+
197
+
For the next test, we posted success on the third PR in the queue, and github seemed to do nothing with that information. But some details to note:
198
+
199
+
- the success status is not even reflected on the merge queue page like the failure status is for the middle one
200
+
- if you go the branches UI, however, you can see the green check on that one
201
+
202
+
So next we posted failure on the first PR in the queue, and this caused github to take the following actions:
203
+
204
+
- PR 7 was indeed removed from the merge queue
205
+
- the merge queue contains only PRs 8 and 9 (8 is ahead, so 9 includes 8, as expected)
206
+
- the old branches for 7,8 and 7,8,9 are still in the branches page with their status
207
+
- the old branch for just 7 is deleted
208
+
- there are new branches listed for 8 and 8,9
209
+
- note these are not the same branch names, just force-pushed, as the branch name includes the base sha
210
+
- e.g. before, the branch for 7 had base sha "sha1" and the branch for 7,8 assumed a base sha w/ 7 having been merged, so when 7 is remove, the new branch for just 8 has base sha "sha1"
211
+
- this means just pushing the new branches to gitlab won't cancel and previous pipelines
To complete this experiment we had @spackbot-test pass both of the new merge_group checks. First we passed the check for PR 9 (which included the changes from both 8,9). This didn't cause github to react in any way, and after nothing happened for awhile, we passed the check for just 8 (the first PR in the merge queue). This caused the following things to happen:
220
+
221
+
- the merge queue became empty, with both PRs (8 and 9) getting merged
222
+
- both of the of the (new) readonly merge queue branches had been deleted
223
+
- received the expected github events associated with merging a PR (mentioned above)
224
+
225
+
One thing to note is that after this experiment, the branches associated with PRs that had to be re-added to the queue when something ahead of them failed seem to just be orphaned. They're still sitting on github right now.
0 commit comments