Closed onigoetz closed 3 years ago
rarkins
commented
3 years ago Exactly how are you running Renovate? Your screenshot shows renovate[bot] but that's an app setup, which is not natively supported by the renovate/renovate image. Have you written some type of custom wrapper?
rarkins
commented
3 years ago As a general guide: if logs are too long for you to be able to sanitize and post, then they're probably also too long for anyone else to review. Focus on a minimal reproduction, sanitize, and share. But tell us more about your exact config first.
onigoetz
commented
3 years ago Yes, I wrote a wrapper that basically runs the Renovate docker image every hour and passes an app token to it.
That's the thing, it only happens on some repositories, it's not reproducible easily on smaller repositories, it seems to happen in cases there are a lot of dependencies updates at the same time.
I understand your point about the logs and I completely agree, but I've never seen this happen on smaller repositories.
It seems I was only able to catch the logs when the PR is re-created, I will try to catch the logs when the PR is closed and extract the lines of useful information from it and come back to you.
rarkins
commented
3 years ago You really need to be capturing debug logs at all times, and make sure they're timestamped. Then look at the commit that caused the branch to close, and correlate it to the logs.
It's helpful if you can generalize on the observations, e.g. does it only happen for "all" repositories, does it only happen for certain package managers, does it only happen on big repositories, etc. That type of information may help.
I assume that Renovate is the only bot you have using that identity too? i.e. you don't have any other scripts which also run with the same app token?
Finally, the full config is relevant, including bot config, repository config, and any presets they extend.
onigoetz
commented
3 years ago yes It's configured to keep only the latest logs, indeed it seems now to be a good idea to also keep older logs :D
yes, renovate is the only app with this specific token, and the scheduler doesn't do any work on the repositories themselves.
We use only two package managers : npm/yarn and maven
My hunch is that happens mainly because of yarn but have nothing to prove it. I will attach the full configuration with the logs as soon as I can get a proper one
onigoetz
commented
3 years ago Side note: I updated this morning to Renovate 24.76.0 the problem persists
So I made a bit more investigation and I extracted this from the logs, I made a short version of the log where I extracted everything that mentions the latest commit and the PR in question (472) I also added a longer version to list everywhere the branch is mentioned
So that would make a small glossary
472e2a3bdc31307eeWhat seems to happen in this log:
renovate/all-minor-patchbranchExists=true, Branch pr rebase requested: falseBranch is up-to-date Branch does not need rebasingEnsuring PR Found PR #472branch status check result (Weirdly, the status refers to the commit 31307ee which is the head of the master branch and NOT the commit that was pushed initially with the PR, which could hint that something went wrong already)PR body changed updatePr(472, Update all non-major dependencies, body)Retrieved closed PR list with graphql For some reason, at this stage 472 is present in the listrarkins
commented
3 years ago It thinks yarn.lock has changed:
DEBUG: yarn.lock needs updating (repository=sq/sq-web-platform, branch=renovate/all-minor-patch)But our own commit logging shows no files have changed:
DEBUG: git commit (repository=sq/sq-web-platform, branch=renovate/all-minor-patch)
"result": {
"author": null,
"branch": "",
"commit": "",
"root": false,
"summary": {"changes": 0, "insertions": 0, "deletions": 0}
}Pushing this is what would cause the PR to be subsequently closed by GitHub.
@viceice can you think of any problem if we were to add a check after git.commit and if changes/deletions/insertions are all 0 then log a warning and abort the git.push?
viceice
commented
3 years ago no, abort should be fine
viceice
commented
3 years ago maybe line ending changes are the cause for renovate to think the lockfile has changed
onigoetz
commented
3 years ago maybe line ending changes are the cause for renovate to think the lockfile has changed
I'm not sure to follow this possibility. I thought that Renovate creates a clean single commit per branch and force-pushes it to update a PR. How does a line ending change make it so that the commit has no content ?
Just trying to understand how it can go from "the lockfile changed" to an empty commit.
You obviously know the tool and codebase way better than I do, just trying to understand :)
viceice
commented
3 years ago A line change cuses a chaneg if we compare the two files as string in javascript, but git is ignoring the last newline change by default. that can be the cause, why renovate sees a lockfile change but git did not.
onigoetz
commented
3 years ago oh okay, but does it start from the latest commit on the PR branch or from the latest commit on the HEAD ?
rarkins
commented
3 years ago It starts with the PR branch and if it detects any changes are necessary then it restarts that branch using the latest base branch commit.
renovate-release
commented
3 years ago :tada: This issue has been resolved in version 24.78.1 :tada:
The release is available on:
24.78.1Your semantic-release bot :package::rocket:
What Renovate type, platform and version are you using?
Describe the bug
A pull Request for minor dependencies updates is created, then closed then on the next run a new one is created. And goes in a forever loop. I'm 100% sure that it's renovate that closes the issue
Relevant debug logs
I can't publish the logs as they are from an internal repository, Is it possible for me to send them by email somehow ?
Have you created a minimal reproduction repository?
Please read the minimal reproductions documentation to learn how to make a good minimal reproduction repository.
I would have time, but can't share a private repository :/
Additional context
I've had this error a few times already, including in public repositories but can't find which ones (when this happens I try to merge as fast as possible as to not create hundreds of PRs.)