Race condition exists for autocommits if future changes are merged before the autocommit

[dbasilio]

Describe the bug

If your CI is building and autocommiting Commit 1, and Commit 2 is introduced between the initial merge and the autocommit, then monodeploy will fail to pull with rebase on Commit 2

• I am interested in contributing a fix.

To reproduce

If the following happens:

• Commit 1 is merged into the main branch
• CI starts building/publishing Commit 1
• Commit 2 is merged into the main branch
• CI finishes building/publishing Commit 1
• CI starts building/publishing Commit 2
• CI autocommits the changelogs from Commit 1 back to the main branch
• CI tries to git pull --rebase on Commit 2, and fails due to the changes from the changelog

Expected behavior

This is hard to say, but I think we should follow a few guiding principles:

• when you merge a commit, that same commit is used for all publishing actions (don't bring in the newer commit too early)
• changelogs should always be added to the latest version
• conflicts should be resolved automatically where possible

Environment (please complete the following information):

• OS:
• Monodeploy Version:
• Yarn Version:
  • Yarn module linker:
• Node Version:
• Git Version:

Additional context

[noahnu]

We could try build in some basic merge conflict resolver 🤔

[Papooch]

I think a simple retry would solve the majority of issues. If monodeploy detects this scenario, it should discard changes and rebase on top of the newest commit and try again, instead of trying to come up with some elaborate conflict resolution logic. What do you think?

[noahnu]

Monodeploy has been forked under a new name Monoweave. I've copied your issue over and will address it in the monoweave project.

monoweave/monoweave#95