The `av` command tool is somehow triggering duplicate GitHub Action Workflows

[jasonroelofs]

I will amend this issue later with something reproducible but wanted to get this written down to see if it's a known issue or known fix. We are running our CI through GitHub Actions and for a while we've had times where people using av end up in a situation where everything is passing, but Aviator fails the merge because it's referencing a workflow run full of cancelled workflows.

These workflows are cancelled due to our concurrency setting, and it turns out that pushing with av (for example av sync --trunk) is triggering the same workflow multiple times. This then gets problematic with Aviator Merge Queue as it picks up only one of these runs and it's a random bet if it will get the cancelled one or the full run.

We've found that doing a normal git push on the same branch kicks Aviator and the Merge Queue process back to a usable state as only one of each workflow is triggered as expected.

Has anyone seen this before? Is this a known issue? Again I'll do some more local testing to see if I can pin down what may be happening and will report back.

An example duplicate and cancel situation we're running into:

Thanks

[jainankit]

Sharing here for posterity: Discussed over email, this might be fixed with the latest upgrade of stack sync. With the latest version, the stack sync only publishes to remote once.

Leaving the ticket open to wait for verification.

[Brookke]

@jainankit Seeing the same thing with av stack submit (version v0.0.39)

[jainankit]

Hi @Brookke, I discussed this briefly over an email chain with @jasonroelofs . We have verified this behavior internally. It seems like even when we do a single git push to multiple branches, GitHub is triggering the webhook and CI multiple times.

Unfortunately, I'm not sure if there's a good solution to avoid this retriggering.

[Brookke]

I need to dig into the code some more, but does AV not just call git push under the hood?