-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected shas for Merge Queues #140
Comments
Hi there @Fitzbert-Fitz ! Thanks for filing an issue! Do you think the changes suggested by @paulo9mv in the PR linked above would solve your issue? Do have a suggested implementation that would make things smoother? |
up! |
I feel like @paulo9mv's solution should work. I can take a stab at testing it. |
I will re-open that PR, since after using this solution for a quite time, it solved my problem and behaved as expected. PR opened: #145 |
Hi there,
as also explained here #100 we encounter massive building overhead due to the sha calculation.
What we would expect:
assume you have two PRs queued in the merge queue. Tha latest main build is successful. We would assume that Queue positon '#1' would derive latest main(successful) as base sha. Position '#2' in the queue would derive position '#1' as base sha since it assumes that position '#1' will pass the queue as well.
But what we see is that the base sha is always the git merge-base / the common ancestor. Meaning Position '1#' in the queue builds all changes since the branch was created not taking into account that builds on main might have been successful in the meantime. The same for position '#1' in the queue. See below:
Looking at the code we do not understand why git merge-base is used here. It might be a good fall back in case you do not find successful commits on main. Maybe miss ordered inside the if else statement?
nx-set-shas/find-successful-workflow.ts
Lines 42 to 62 in 76907e7
The text was updated successfully, but these errors were encountered: