Release workflow tanks as auto merge workflow jumps in

[jonaslagoni]

Reason/Context

After trying to release Modelina next branch, it was merged, and right after (before the release commit) the auto-merge workflow merged a newly created dependency bump, meaning the release commit did not release anything https://github.com/asyncapi/modelina/actions/runs/3987699301/jobs/6838096588. And I cannot re-run it, as it's tied to the commit before the dependency update, meaning I will keep getting the error The local branch master is behind the remote one, therefore a new version won't be published..

And the dependency bump PR of course don't trigger release asyncapi/modelina@54584cf

[jonaslagoni]

Not sure what exactly the solution to this is.

One solution would be for the auto-merge workflow to check that before merging there is no commit that needs to be released and it's "safe" to auto-bump dependencies.

[derberg]

Got it. Sometimes because of tests release workflow takes time, and in the meantime something else can be merged in and this is why behind error.

Apparently it is not a new problem and known to semantic-release maintainers -> semantic-release/semantic-release#1849 but strangely they do not want to accept new config option allowOutdatedBranch and many community members work on fork semantic-release/semantic-release#1850

One solution would be for the auto-merge workflow to check that before merging there is no commit that needs to be released and it's "safe" to auto-bump dependencies.

Definitely something like this is better than switching to fork of semantic-release. I do not think though that it is only relevant for automerge PRs. There can be cases that someone also manually merge a PR not knowing there is a release workflow still running.

@jonaslagoni @KhudaDad414
what about having a dedicated workflow called "can this be merged", that would be required, that basically would query all release workflow runs and if there is still one release workflow running, it would fail? and therefore block merge. We could even add PR command to support "rerunning" of the "can this be merged" workflow.

This new workflow would be triggered by 2 events:

• submitted approval review? maybe?
• workflow_run to also automatically rerun it when release workflow completed?

should be super simple to check with GitHub CLI or in different ways.

Thoughts?

[KhudaDad414]

@derberg How would the auto-merge workflow reacts in this scenario?
release workflow is running -> bot opens a PR and adds the automerge label -> auto-merge workflow fails because "can this merge" failed -> release workflow completes -> "can this merge" succeeds. then what? I mean do we have to run the auto-merge workflow manually?

[derberg]

good question @KhudaDad414

for now we would just get an alert to slack next day that some bot pr was not merged, and we would have to jump in and react (manually rerun)

but we can chain automerge as well and make it also react once "can this merge" is competed

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️