renovate/renovate
1
0
Fork 0
mirror of https://github.com/renovatebot/renovate.git synced 2025-01-12 15:06:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 7

docs(pull requests): rewrite (#21440)

Browse source 
Co-authored-by: Rhys Arkins <rhys@arkins.net>
This commit is contained in:
HonkingGoose 2023-04-13 10:44:41 +02:00 committed by GitHub
parent 33829bab77
commit 734ab7f421
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 18 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
docs/usage/key-concepts/pull-requests.md
View file

@ -7,23 +7,31 @@ This page describes how Renovate pull requests work.
## How Renovate finds existing PRs ## How Renovate finds existing PRs
Renovate does not keep any kind of database/state of its own about open or closed Pull Requests. Renovate does not need to maintain any database/state about open or closed Pull Requests.
Instead, it uses the code platform's APIs to search and find such PRs. Instead, it uses the code platform's APIs to search and find such PRs.
Locating of existing PRs - whether open or closed - is done by matching both the branch name (e.g. `renovate/lodash-4.x`) and Pull Request title (e.g. `Update lodash to v4.17.21`). Renovate finds existing PRs (open or closed) by matching both:
In cases like the above, there is typically at most one existing PR with the desired branch + title combination. - the branch name, for example: `renovate/lodash-4.x`,
When grouping is enabled by users, and PRs have titles like "All non-major updates", then there may be multiple past PRs which match. - _and_ the Pull Request title, for example: `Update lodash to v4.17.21`
In cases like the above, there is typically one existing PR with a matching branch name and PR title.
But if you group PRs and use titles like "All non-major updates", then multiple past PRs may match.
## Normal PRs ## Normal PRs
As described above, Renovate PRs normally have some uniqueness in their title relating to the version in the upgrade. As explained above, Renovate PRs normally have some "uniqueness" in their title relating to the version in the upgrade.
In such cases, if a user closes such a PR, it can be inferred that they don't want to see it again in future. When you close a "unique" PR, Renovate assumes you don't want to see that PR again in future, for example:
For example, they wish to ignore `lodash@4.17.21`.
In such cases, new PRs won't be created until the branch+title uniqueness exists again, such as if there is a `lodash@4.17.22`. 1. You ignored `lodash@4.17.21` by closing Renovate's PR
1. Renovate assumes you don't want any updates to `4.17.21` of `lodash`
1. Renovate creates a new PR when the branch + title "uniqueness" exists again, like when `lodash@4.17.22` releases
Similarly in the case of major updates (such as "Update lodash to v4") then it can be inferred that the user wishes to ignore all of v4 of `lodash`, even when newer v4 versions are available. Renovate behaves similarly for `major` updates, for example:
1. You ignored a `major` update for Lodash (pr title: "Update lodash to v4") by closing Renovate's PR
1. Renovate assumes you don't want any updates to `v4` of `lodash`
1. Renovate won't create any update PRs for `v4` of `lodash`, even if there are newer versions of `v4`
## Immortal PRs ## Immortal PRs
@ -62,7 +70,7 @@ Then the update becomes "Update react (major)", which is not safely ignorable, i
### Future plans for immortal PRs ### Future plans for immortal PRs
In the future we may embed metadata in each PR identifying the exact files and packages + versions that PR contains. In the future we may embed metadata in each PR identifying the exact files and packages + versions that PR contains.
Then we could allow such PRs to be closed/ignored but then as soon as there's any chance to files/packages/versions being updated then we'd be cached busted and create a new PR. Then we could allow such PRs to be closed/ignored but then as soon as there's any chance to files/packages/versions being updated then we'd be cache busted and create a new PR.
If you regularly wish to close immortal PRs, it's an indication that you may be grouping too widely. If you regularly wish to close immortal PRs, it's an indication that you may be grouping too widely.
### How to fix immortal PRs ### How to fix immortal PRs