Renovate ignores Git fixup commits for Copier template updates

[sthdev]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

GitHub, Renovate 39

Please tell us more about your question or problem

Sometimes, PRs created by Renovate need to be manually extended. Normally, Renovate detects additional commits created by other users and does not rebase the PR.

However, we sometimes use the Git fixup method (see e.g. https://mikulskibartosz.name/git-fixup-explained) to extend commits created by Renovate. Using this method results in a single commit in the PR, which is authored by renovate as well as the user that extended it.

In this case, Renovate does not detect that the PR was manually modified if it is a PR for a dependency to a Copier template. Therefore, when Renovate runs the next time, it rebases the PR and throws away the extended commit. We can work around this problem by adding the stop-updating label to the PR. However, people have to think about this.

For some reason, this seems to only happen in case of PRs for Copier dependencies. The reproduction repository at https://github.com/sthdev/renovate-33658 also tests the behavior with a dependency in a Dockerfile. There, the manually extended commit is preserved.

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[viceice]

Renovate only checks the commit author and it's probably not easily doable / desired to check the committer

renovate/lib/util/git/index.ts

Line 674 in 1d64a10

committedAuthors.add(commit.author_email);

[rarkins]

Yes, the latter. Existing PRs will be updated if either:

• renovate thinks they need a change, or
• they need rebasing according to the configured policy

It sounds like the copier manager is always returning "an update to this branch is needed"

[rarkins]

But maybe that's because you're modifying the branch contents and copier wants to modify it back

[sthdev]

After digging into the Renovate code base and taking a closer look at the logs, I made the following observations:

• Renovate does not detect that the branches were modified, neither the Copier nor the Dockerfile branch (see https://github.com/sthdev/renovate-33658/actions/runs/12863263259/job/35859526746#step:4:706 and https://github.com/sthdev/renovate-33658/actions/runs/12863263259/job/35859526746#step:4:706). This seems to be caused by the fact that Renovate looks for commit authors that it does not recognize (see

  renovate/lib/util/git/index.ts

  Line 728 in cbf5303

  { branchName, unrecognizedAuthors: [...includedAuthors] },

  ). But in these cases, the only commit author is renovate itself.
• In both cases, there is a line in the log Using reuseExistingBranch: true (see https://github.com/sthdev/renovate-33658/actions/runs/12863263259/job/35859526746#step:4:721 and https://github.com/sthdev/renovate-33658/actions/runs/12863263259/job/35859526746#step:4:825). However, the Copier manager does not seem to honor this. The next line in the log is Setting current branch to main and further down Need to update package file so will rebase first (see https://github.com/sthdev/renovate-33658/actions/runs/12863263259/job/35859526746#step:4:728). Then, Copier is run on the main branch to update the code to the new template version. This, of course, discards any changes made to the existing branch.

So the behavior of the Copier manager is inconsistent. This seems to be a side-effect because the manager always runs copier update, which not only updates the file that declares the dependency itself (like the from line in the Dockerfile or like most other dependency declarations) but updates potentially any other file in the repository.

One (naive) idea to fix this, is to compare the result of running copier update on the main branch with the existing PR branch. If there is a difference, someone has changed it. But that change may also be the result of another update of the Copier template that happened in the meantime. :-(

[rarkins]

This is why we don't recommend this git-level approach to modifications of Renovate branches. Either:

• Make the changes in a new commit, and squash the branch when merging, or
• Make the changes and force push with a different identity, so that Renovate can detect that the branch is modified

At that point Renovate will stop updating the branch, because it detects it as modified. You have the choice to keep the branch paused from future updates until you merge it, or wipe away the changes by ticking the rebase/retry box.

[sthdev]

Unfortunately, both of these cause other problems further down the road. But thanks for the information and for taking the time to look into this.

[github-actions[bot]]

Hi there,

Get your discussion fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

Please follow these steps:

1. Read our guide on creating a minimal reproduction.
2. Go to our minimal reproduction template repository.
3. Select the Use this template button to create a new repository based on the template.
4. Work on the minimal reproduction in your own repository.
5. Fill out the information in your repository's README.md.
6. Add the link to your reproduction to the first post of your Discussion. If you are not the original author, you can post a new comment with the link.

If you need help with running renovate on your minimal reproduction repository, please refer to our Running Renovate guide.
Good luck,

The Renovate team