Gitlab MRs not updated and marked with "MR has been edited" comment on 2nd run

[dominik-bln]

What Renovate type are you using? Renovate CLI v16.7.4

Describe the bug

MRs in Gitlab are correctly opened but the bot adds a comment that the "MR has been edited" the next time it runs even though they only have the single renovate commit and then does not update the MRs anymore.

Did you see anything helpful in debug logs?

Only basic info output that the MRs are created on 1st run and this on the 2nd run:

INFO: Added comment (repository=alpha%2Falpha, dependencies=django-taggit, branch=ren/django-taggit-0.x)
       "issueNo": 2383
 INFO: Added comment (repository=alpha%2Falpha, dependencies=django-watchman, branch=ren/django-watchman-0.x)
       "issueNo": 2384

To Reproduce

Not completely sure, please let me know if I can somehow help to reproduce this.

Only thing I can say is that this was not present on Renovate v14.x, but as we also update Gitlab frequently it could have been caused by a recent update of Gitlab as well.

Expected behavior

Renovate continues to update the MRs when a new update arrives before they are merged.

Screenshots

Every single renovate MR has one comment by the bot (disregard the pipeline errors, they are caused by a different issue):

All of the MRs have just the single bot commit:

Additional Context

Gitlab is self hosted in version 11.10.1

[rarkins]

Are you using gitFs, or regular API-based committing?

[dominik-bln]

Regular commits via CLI.

[Autre31415]

I'm seeing this bug as well after updating renovate, so it must have been introduced within the past month or so.

Gitlab Community Edition 11.10.0

[toxsick]

Same thing here:

Gitlab CE 11.8.0 Renovate 16.10.4

[rarkins]

Is anyone able to approximate which Renovate release this happened in?

We create this comment if pr.canRebase === false: https://github.com/renovatebot/renovate/blob/49c4ad07c7b6230fe44313987a20caf9470030a5/lib/workers/branch/index.js#L126

canRebase is set during getPr(), and it sets it to true if the last committer matches the bot's email: https://github.com/renovatebot/renovate/blob/49c4ad07c7b6230fe44313987a20caf9470030a5/lib/platform/gitlab/index.js#L700-L706

The bot's email is set during init: https://github.com/renovatebot/renovate/blob/49c4ad07c7b6230fe44313987a20caf9470030a5/lib/platform/gitlab/index.js#L124

I can't figure out where the logic is failing. Commit history for gitlab platform is here: https://github.com/renovatebot/renovate/commits/master/lib/platform/gitlab/index.js

[toxsick]

For me this seems to have started somewhere between v16.5.4 and v16.5.8 on the 25.04 I think

[rarkins]

That would point at this commit, but I can't work out why: https://github.com/renovatebot/renovate/commit/788215a

[rarkins]

I've added extra debugging in renovate@16.10.5: https://github.com/renovatebot/renovate/commit/d3dbd93

[dominik-bln]

DEBUG: Last committer to branch does not match bot email, so PR cannot be rebased. (repository=leave-manager/lm_frontend, dependencies=jquery, branch=renovate/jquery-3.x)
       "branchCommitEmail": "bot@renovateapp.com",
       "configEmail": "renovate-bot@something.private",
       "iid": 137

[dominik-bln]

I've added gitAuthor: 'Renovate Bot <renovate-bot@something.private>' to the config now and am waiting on the next MR to be opened.

[dominik-bln]

Setting gitAuthor with the email of the bot user fixes the problem for us.

[viceice]

renovate v17 drops api based git operations, so this should fixed by #3601

[viceice]

try to use gitFs=http or https or ssh as workaround for now. gitAuthor should always be set on self-hosted renovate.

[rarkins]

@ViceIce thanks for chiming in. I held back on mentioning it myself as I wasn't 100% sure if the same problem would happen in v17 if gitAuthor was still unset. i.e. maybe the problem is independent of gitFs?

[viceice]

I've never seen this problem on my self-hosted gitlab instance

[dominik-bln]

I'm happy with closing as this was mainly a configuration issue. Some UX notes from my user perspective:

• at least when I configured it, the docs weren’t clear that gitAuthor needs to be set
• I somehow expected the bot to know its email without configuration (I see that this is probably not trivial though)
• logging the user mismatch at Info level could help other users to find the misconfiguration
• the docs of gitAuthor could use an example, the RFC mentioned is pretty long and not really specific to the problem at hand

Thanks everyone for looking into this.

[toxsick]

For me it was also solved by passing the email address of the renovate user with --git-author from the commandline. Understanding what what happened now I agree with @dominik-bln that the user mismatch should at least appear in Info log level.

Thanks everybody!

[rarkins]

The latest Renovate detects the email address of the bot account and uses that as gitAuthor, so this problem should now be resolved. Make sure your tokens include user permissions though so that the email address can be read.