Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rebase checkbox remains checked after rebase when prCreation=not-pending #5951

Closed
edmorley opened this issue Apr 12, 2020 · 18 comments · Fixed by #6691
Closed

Rebase checkbox remains checked after rebase when prCreation=not-pending #5951

edmorley opened this issue Apr 12, 2020 · 18 comments · Fixed by #6691
Labels
priority-2-high Bugs impacting wide number of users or very important features type:bug Bug fix of existing functionality

Comments

@edmorley
Copy link
Contributor

edmorley commented Apr 12, 2020

What Renovate type are you using?

Hosted App

Describe the bug

The Renovate bot does not untick the "rebase" checkbox, after performing the rebase. It used to do so, but stopped a while back (a few months ago?).

Did you see anything helpful in debug logs?

Did not look

To Reproduce

  1. Open a renovate PR that needed rebasing (eg Update dependency prettier to v2 neutrinojs/webpack-chain#250)
  2. Tick the rebase checkbox in the PR description
  3. Wait for the bot to push new commits
  4. Refresh the PR page
  5. Look at the status of the rebase checkbox in the PR description

Additional context

This is causing PR additional commits to be clobbered. (eg rebase a PR, add a new commit such as running prettier again after a prettier upgrade, so the CI passes -- then renovate rebases over it, since the checkbox is still ticked)

@rarkins
Copy link
Collaborator

rarkins commented Apr 12, 2020

@viceice I wonder if it was this change?

// Don't create a branch if we know it will be status 'pending'
if (
!masterIssueCheck &&
!branchExists &&
config.stabilityStatus === BranchStatus.yellow &&
['not-pending', 'status-success'].includes(config.prCreation)
) {
logger.debug('Skipping branch creation due to stability days not met');
return 'pending';
}

@viceice
Copy link
Member

viceice commented Apr 12, 2020

Maybe, I'm not sure. Maybe we need to check for rebase request there. So we need to update pr if it exists 🤔

@KnisterPeter
Copy link

We updated yesterday from renovate 19 to 21 (self hosted).
Since then we see a few hundred builds triggered on our CI, caused by this checkboxes.

@KnisterPeter
Copy link

KnisterPeter commented Jun 10, 2020

In our logfiles I've seeing this entries:

DEBUG: Processing existing PR (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
DEBUG: PR body changed (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
       "prTitle": "fix(deps): update dependency @sentry/cli to v1.54.0 (master)",
       "oldPrBody": "This PR contains the following updates:\n\n| Package | Type | Update | Change |\n|---|---|---|---|\n| [@sentry/cli](https://docs.sentry.io/hosted/learn/cli/) ([source](https://github.com/getsentry/sentry-cli)) | dependencies | minor | [`1.52.1` -> `1.54.0`](https://renovatebot.com/diffs/npm/@sentry%2fcli/1.52.1/1.54.0) |\n\n---\n\n### Release Notes\n\n<details>\n<summary>getsentry/sentry-cli</summary>\n\n### [`v1.54.0`](https://github.com/getsentry/sentry-cli/blob/master/CHANGELOG.md#sentry-cli-1540)\n\n[Compare Source](https://github.com/getsentry/sentry-cli/compare/1.53.0...1.54.0)\n\n-   feat: Add `--no-environ` parameter to `bash-hook` ([#&#8203;745](https://github.com/getsentry/sentry-cli/issues/745))\n-   feat: Allow for disabling install progress-bar without silencing npm using `SENTRY_NO_PROGRESS_BAR` env var ([#&#8203;754](https://github.com/getsentry/sentry-cli/issues/754))\n-   fix: Use correct required option to `newDeploy` JS api ([#&#8203;755](https://github.com/getsentry/sentry-cli/issues/755))\n\n### [`v1.53.0`](https://github.com/getsentry/sentry-cli/blob/master/CHANGELOG.md#sentry-cli-1530)\n\n[Compare Source](https://github.com/getsentry/sentry-cli/compare/1.52.4...1.53.0)\n\n-   feat: `releases deploys` JavaScript API ([#&#8203;741](https://github.com/getsentry/sentry-cli/issues/741))\n-   fix: `--log-level` should be case insensitive ([#&#8203;740](https://github.com/getsentry/sentry-cli/issues/740))\n\n### [`v1.52.4`](https://github.com/getsentry/sentry-cli/blob/master/CHANGELOG.md#sentry-cli-1524)\n\n[Compare Source](https://github.com/getsentry/sentry-cli/compare/1.52.3...1.52.4)\n\n-   fix: Dont panic on unknown log level ([#&#8203;733](https://github.com/getsentry/sentry-cli/issues/733))\n-   ref: Use temp dir to store jsbundle maps ([#&#8203;737](https://github.com/getsentry/sentry-cli/issues/737))\n\n### [`v1.52.3`](https://github.com/getsentry/sentry-cli/blob/master/CHANGELOG.md#sentry-cli-1523)\n\n[Compare Source](https://github.com/getsentry/sentry-cli/compare/1.52.2...1.52.3)\n\n-   fix: Correctly store child process before attaching handlers ([#&#8203;718](https://github.com/getsentry/sentry-cli/issues/718))\n\n### [`v1.52.2`](https://github.com/getsentry/sentry-cli/blob/master/CHANGELOG.md#sentry-cli-1522)\n\n[Compare Source](https://github.com/getsentry/sentry-cli/compare/1.52.1...1.52.2)\n\n**This release sets `node.engine: >=8` which makes it incompatible with Node v6**\nIf you need to support Node v6, please pin your dependency to `1.52.1`\nor use selective version resolution: <https://classic.yarnpkg.com/en/docs/selective-version-resolutions/>\n\n-   feat: Support Google Cloud Builder VCS detection ([#&#8203;481](https://github.com/getsentry/sentry-cli/issues/481))\n-   fix: Mark files as unusable withid ([#&#8203;709](https://github.com/getsentry/sentry-cli/issues/709))\n\n</details>\n\n---\n\n### Renovate configuration\n\n📅 **Schedule**: At any time (no schedule defined).\n\n🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.\n\n♻️ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.\n\n🔕 **Ignore**: Close this PR and you won't be reminded about this update again.\n\n---\n\n - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box\n\n---\n\nThis PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).",
       "newPrBody": "This PR contains the following updates:\n\n| Package | Type | Update | Change |\n|---|---|---|---|\n| [@sentry/cli](https://docs.sentry.io/hosted/learn/cli/) ([source](https://github.com/getsentry/sentry-cli)) | dependencies | minor | [`1.52.1` -> `1.54.0`](https://renovatebot.com/diffs/npm/@sentry%2fcli/1.52.1/1.54.0) |\n\n:warning: Release Notes retrieval for this PR were skipped because no github.com credentials were available.\nIf you are using the hosted GitLab app, please follow [this guide](https://docs.renovatebot.com/install-gitlab-app/#configuring-a-token-for-githubcom-hosted-release-notes). If you are self-hosted, please see [this instruction](https://github.com/renovatebot/renovate/blob/master/docs/development/self-hosting.md#githubcom-token-for-release-notes) instead.\n\n---\n\n### Renovate configuration\n\n📅 **Schedule**: At any time (no schedule defined).\n\n🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.\n\n♻️ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.\n\n🔕 **Ignore**: Close this PR and you won't be reminded about this update again.\n\n---\n\n - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box\n\n---\n\nThis PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate)."
DEBUG: updatePr(955, fix(deps): update dependency @sentry/cli to v1.54.0 (master), body) (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
DEBUG: PR updated (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
       "pr": 955
 INFO: PR updated (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
       "pr": 955,
       "prTitle": "fix(deps): update dependency @sentry/cli to v1.54.0 (master)"

But after renovate finishes the PR isn't changed (even though the log says DEBUG: PR updated).
Next time the body will again be changed, this will trigger a loop I think.

Seems to be my local test 🙄

@rarkins
Copy link
Collaborator

rarkins commented Jun 10, 2020

I’ve found some times you need a hard refresh of the page to see the updated PR. Always check it in an incognito browser to be sure. This is a GitHub UI problem when that happens, not Renovate

@KnisterPeter
Copy link

Not sure but maybe these lines are helping:

DEBUG: exec completed (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
       "cmd": "yarn install --ignore-engines --ignore-platform --network-timeout 100000 --ignore-scripts",
       "durationMs": 1101,
       "stdout": "yarn install v1.22.4\n[1/4] Resolving packages...\nsuccess Already up-to-date.\nDone in 0.94s.\n",
       "stderr": ""
DEBUG: yarn.lock needs updating (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
DEBUG: Updated 1 lock files (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
       "updatedArtifacts": ["yarn.lock"]
DEBUG: 2 file(s) to commit (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
DEBUG: Committing files to branch renovate/master-sentry-cli-1.x (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
 INFO: Branch updated (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
       "commitHash": "c6d7977"
DEBUG: Branch status pending (repository=fea/hops, branch=renovate/master-sentry-cli-1.x)
       "commitHash": "c6d7977"

Its says here that yarn install is executed, then that its up-to-date.
But renovate has two files to commit and one 'updatedArtifacts' - the yarn.lock.

@KnisterPeter
Copy link

If I run yarn install --ignore-engines --ignore-platform --network-timeout 100000 --ignore-scripts locally checkouted on the renovate/master-sentry-cli-1.x branch there is no difference generated for the yarn.lock

@KnisterPeter
Copy link

Forget my comments above as well. These are, because the branch is recreated and compared to the base (caused by the checkbox)...

@KnisterPeter
Copy link

KnisterPeter commented Jun 10, 2020

So, now I think I have the cause:

  1. The branch is recreated
  2. It is flagged as pending
  3. No update of the PR is done, because the branch is pending -> the checkbox is not unflagged.

I guess if its pending but the checkbox is ticked, the PR need to be updated.
But there isn't even checked if a PR exists, because it is returned early in processBranch.

Another option would be to skip processBranch if the branch status is pending at the start.

@rarkins
Copy link
Collaborator

rarkins commented Jun 10, 2020

I think we should update the PR as otherwise it will be rebased every run, right? What config reproduces this?

@KnisterPeter
Copy link

Just the default but :prNotPending is defined.

@rarkins
Copy link
Collaborator

rarkins commented Jun 10, 2020

So what's the full steps, is it:

  • Have an onboarded repository with an outdated dependency
  • Wait for Renovate to create a PR (note: once tests pass)
  • Tick the rebase checkbox ?

@KnisterPeter
Copy link

Oh, sorry. Yes thats the way. If there is a PR and that is fine (or outdated), then ticking the checkbox leads to this cycle.
I already can confirm that changing prCreation to the default will fix this.

@rarkins
Copy link
Collaborator

rarkins commented Jun 10, 2020

And can you confirm if you're using the app, or a particular self-hosted version?

@KnisterPeter
Copy link

KnisterPeter commented Jun 10, 2020

Thats self-hosted. We have a custom setup for our internal github enterprise.
The renovate version is 21.6.2.

@edmorley
Copy link
Contributor Author

This issue still affects us too fwiw (GitHub app, not self hosted)

@edmorley
Copy link
Contributor Author

We also use :prNotPending (https://github.com/neutrinojs/webpack-chain/blob/master/renovate.json) which matches the observations above :-)

@rarkins rarkins changed the title Rebase checkbox is no longer unchecked after the rebase performed Rebase checkbox remains checked after rebase when prCreation=not-pending Jun 10, 2020
@rarkins rarkins added type:bug Bug fix of existing functionality priority-2-high Bugs impacting wide number of users or very important features ready labels Jun 10, 2020
@rarkins rarkins removed the ready label Jun 18, 2020
rarkins added a commit that referenced this issue Jul 7, 2020
rarkins added a commit that referenced this issue Jul 7, 2020
@renovate-release
Copy link
Collaborator

🎉 This issue has been resolved in version 21.24.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
priority-2-high Bugs impacting wide number of users or very important features type:bug Bug fix of existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants