-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Lazy onboarding PR refresh #20537
Comments
We should explain the refreshing behavior in the PR body text for the Onboarding PR:
|
I don't undertand point (1) |
I thought we are clever enough to check if the only change to the branch is |
Checked That aside I tried to see how the the recently added |
It's not what I expected |
Repeating what you said, For platforms that don't support a checkbox maybe we can modify the prTitle or ask user to add a comment. Implementation wise: |
I had half forgotten about that feature. Actually, there's two different possibilities which checkboxes could satisfy:
They're similar concepts but in the latter you'd wipe away your |
Summarizing:
I don't get what "refresh" means in this context. I assume its just refers to the normal run. |
I'm thinking of changed requirements: First of all, we need to be prepared that not all platforms support checkboxes, so we need to revert back to normal behavior if no checkbox is present in the PR. Then, it seems like we should have at most one checkbox in an onboarding PR, which will "refresh" the onboarding PR from main either way, but in the case that the config is modified, it should display a warning next to the checkbox that custom changes will be lost. So logic is like this:
So the idea is:
|
|
Do I understand correctly that you are proposing we can reuse the existing feature almost as-is, and it satisfies my use case? BTW I'm most interested in GitHub for now |
Yes with minor additions. |
I think we should not use 2 messages for the rebase checkbox because then we will have to call Instead we can add a diffrent msg that warns user that opting for rebase on a modified PR will cause the changes to be lost. |
If we use the idea you suggested to embed branch commitSHA into PR body. The flow to check for modified branch will be like below I assume:
|
I'm ok with us warning about changes being lost as a first step |
Note: This PR #20702 isn't enough to prevent cloning. More work need to be done. |
What would you like Renovate to be able to do?
Avoid refreshing onboarding PRs every time there's a commit to the default branch. Onboarding PRs sometime remain open for a long time and users don't need it refreshed non-stop.
If you have any ideas on how this should be implemented, please tell us here.
For platforms which support checkboxes, only refresh onboarding PRs when either:
If the PR isn't checked or the branch not modified, skip cloning and any other work.
We might need to do some brainstorming on whether the first point requires repositoryCache to be enabled or not. One alternative is to embed the branch commit SHA into the PR body
Is this a feature you are interested in implementing yourself?
No
The text was updated successfully, but these errors were encountered: