search

asyncapi / .github

Location of all reusable community health files
29 stars 62 forks source link

Release workflow tanks as auto merge workflow jumps in #207

Open jonaslagoni opened 1 year ago

jonaslagoni commented 1 year ago

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 https://github.com/asyncapi/modelina/commit/54584cf3c84161c9e6fbfda677e990677b74c5a9

jonaslagoni commented 1 year ago

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 commented 1 year ago

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 -> https://github.com/semantic-release/semantic-release/issues/1849 but strangely they do not want to accept new config option allowOutdatedBranch and many community members work on fork https://github.com/semantic-release/semantic-release/pull/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:

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

Thoughts?

KhudaDad414 commented 1 year ago

@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 commented 1 year ago

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[bot] commented 11 months ago

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

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 :heart: