Fail a copier renovate update when merge conflicts are present

[PJ-Schulz]

Tell us more.

A merge conflict can occur during a copier update if a manual change has been made between two versions. I have reproduced this behavior in an example repository. This is the PR Renovate creates: PJ-Schulz/my-renovate-test#3

In this snipped you can see the example merge conflict:

      containers:
      - name: my-app
<<<<<<< before updating
        image: nginx:alpine
=======
        image: nginx:1.27.1
>>>>>>> after updating
        resources:
          limits:

Currently Renovate only writes a comment in the Pull Request. In my opinion, it would be better if there was an artifact update error and the update was interpreted as failed. This way a person can manually resolve the conflict.

[rarkins]

Please rewrite this above to remove all mention of merging or automerging because that is not the root problem. Please also remove automerge from the reproduction repo and make the config minimal. You have 30+ lines of config of which I think 30 are probably unnecessary.

The reproduction should be a repo which has a PR open demonstrating the type of conflict.

The problem to solve here is that Renovate should mark such conflicts as artifact update errors and not "absorb" them.

[PJ-Schulz]

done

[lkubb]

I wrote the code like this intentionally because* it allows to quickly resolve conflicts (eg via the web UI) instead of having to do everything manually. When automerging, one must have a CI check for merge conflict markers though. In general, I'm not sure if Copier updates should be automerged at all, they are much more brittle than regular dependency updates.

Failing the update instead of just warning about conflicts means I have to perform the following additional steps:

• checkout the repository locally
• create a branch
• run copier update manually
• create a PR after fixing the conflicts
• possibly request another reviewer if branch protection is active and I can't/don't want to override it

* in addition to glossing over erroneous merge conflicts, which could still be handled with your proposal

[rarkins]

Yes, it's an important consideration that failing checks will mean that non-admins in a repo can't merge, even if they fix the reason for the failing check