Unexpected shas for Merge Queues

[Fitzbert-Fitz]

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

	if (
	(["pull_request", "pull_request_target"].includes(eventName) &&
	!github.context.payload.pull_request.merged) ||
	eventName == "merge_group"
	) {
	try {
	const mergeBaseRef = await findMergeBaseRef();
	const baseResult = spawnSync(
	"git",
	["merge-base", `origin/${mainBranchName}`, mergeBaseRef],
	{ encoding: "utf-8" }
	);
	BASE_SHA = baseResult.stdout;
	} catch (e) {
	core.setFailed(e.message);
	return;
	}
	} else {
	try {
	BASE_SHA = await findSuccessfulCommit(
	workflowId,

[mandarini]

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?

[andersonba]

up!

[scottkgaran]

I feel like @paulo9mv's solution should work. I can take a stab at testing it.

[paulo9mv]

I will re-open that PR, since after using this solution for a quite time, it solved my problem and behaved as expected.
On the merge_group event the expected behaviour is that base SHA is the previous commit on the queue (or the head commit on main branch, if queue is size 1)

PR opened: #145

[brimac2]

Up!

[paulo9mv]

@mandarini @meeroslav would you mind reviewing the PR #145 ?

[jordanpowell88]

@Fitzbert-Fitz can you confirm #145 fixes your issue?

[ethantkoenig]

The change in #145 does not work for merge queues where the "Only merge non-failing pull requests" option (see Managing a merge queue in the GitHub docs) is false. In particular, see this portion of the description of the option being set to false:

If the last pull request in the group has passed required checks, this means that the checks have passed for the combined set of changes in the merge group.

Can the "set base SHA to HEAD^" behavior introduced in #145 be made an option, rather than the default/only behavior?