Update workflows to run merge queue on GH runners #8863
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 4 Skipped Deployments
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of https://ledgerhq.atlassian.net/browse/LIVE-14748
Updates our workflows so that
build-and-test-prworkflows are run on Github runners if the triggering event is a merge queue group. This anticipates the activation of a merge queue ondevelop, as has been done in the device-sdk-ts repo.Testing this PR will be tricky.
merge_groupwebhook, at which point we will need to confirm that all the affected jobsa) run on the correct runners
b) run without error
build-and-test-prrun in a PR checks setting (pre-merge-queue) and ensure that:a) run on the original runners (same as they do today)
b) run without error
# 2 is easier to test because it'll come for free in the pre-merge PR checks while testing # 1.
I recommend we do testing late in the evening at the end of a workday, announcing to #live-engineering in advance, or at a weekend. An alternative is to create a clone/fork of the entire ledger-live repo, configure it as per ledger-live (may take some time) and run a dry run rehearsal, but I think that has the potential to turn really quite complex and end up taking much more time than we want to spend on this. Therefore, merge strategy is to merge at the end of a workday, in advance of an end-of-workday session where we turn on the merge queue and validate that it works.