Migrate to Merge Queues

[0152la]

No description provided.

[0152la]

I would like to merge this in as there's a subtle difference I can't replicate vis-a-vis our softdev org repos - filtering out CI on pushing to the PR versus clicking "merge when ready" (as I've not seen the expected behaviour for the latter). Updating this repo should give me some insight into what's happening.

[ltratt]

I don't know if this makes a difference but in this repo the file is .github/workflows/merge.yml but in the softdev repos it's .github/workflows/sdci.yml?

[0152la]

It shouldn't matter what the name is, unless it appears on buildbot's side. And these repos have a separate buildbot backend than the softdev ones. However if you'd like the same name for consistency, I don't have too strong an opinion. I think it might be some behaviour that needs some trigger that I see in usual usage, and I missed during my testing.

[ltratt]

Ah, SoftDevCi -- I didn't even realise what it stood for! OK, the name isn't important.

[ltratt]

@0152la Do we need to disable auto-merge for this PR?

[0152la]

Hah. So I think how this works is you can't manually trigger a CI, but this "auto-merge" will just merge when CI passes. Meaning I think I have to push something else to trigger the CI here. I'll check with Edd and see.

[0152la]

I need to do some further testing with merge queues - I'll make a test repo for that. My assumption for this PR is that we just have to manually rerun the last failing job in buildbot, and it'll merge. However, there's one thing after talking with Edd that doesn't match up, and it's quite important.

[0152la]

@ltratt Alright, I've done my testing. I think this migration is an all or nothing, and the issues I've seen was cause I was doing it gradually. I now have the back-end buildbot support right, and nothing should change in this PR for the migration. I can rerun it manually, or do a force-push with a dummy squash to re-trigger the CI, as you prefer.

[ltratt]

I can rerun it manually, or do a force-push with a dummy squash to re-trigger the CI, as you prefer.

Why don't you do a force push with an updated time (I sometimes use git commit --amend --date now for this). That's easiest I think?

[0152la]

Didn't know that trick - thanks.