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

feat(platform/github): flag to control whether PRs can be edited by maintainers if forkTokenis set #19771

Merged
merged 9 commits into from
Feb 22, 2023

Conversation

devversion
Copy link
Contributor

@devversion devversion commented Jan 10, 2023

Changes

A new option called forkModeAllowMaintainerEdits is introduced. This option is only relevant if Renovate is used with forkToken.

  • The option is by default true, keeping backwards compatibilty
  • The option will only have an effect for github.

The option decides whether maintainer edits are allowed to edit pull requests.

Context

If a maintainer pushes changes to a fork renovate PR, the branch will never be deleted by Renovate because there are changes not corresponding to the Git account configured in Renovate.

This prevents future updates as Renovate basically locks down the branch and marks it as pr-edited, preventing it from being overridden or cleaned-up as part of the scheduled branch deletion.

We can fix this by encouraging that maintainers cherry-pick the commit and make changes in a separate PR. Users of the experimental fork mode option can do this by setting prAllowMaintainerEdits = false. It is not possible for maintainers to trivially delete the branch of the e.g. fork robot account because they would need to log into that and not every team member would e.g. necessarily have access to the robot account.

Documentation (please check one with an [x])

  • I have updated the documentation, or
  • No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

  • Code inspection only, or
  • Newly added/modified unit tests, or
  • No unit tests but ran on a real repository, or
  • Both unit tests + ran on a real repository

@rarkins rarkins marked this pull request as draft January 10, 2023 17:35
Copy link
Member

@viceice viceice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needs to be configurable and enabled by default to be not breaking

devversion added a commit to devversion/renovate that referenced this pull request Jan 24, 2023
This commit ensures the GitHub platform logic respects the
new `prallowMaintainerEdits` option.

Whenever a PR is created, depending on the option value,
the GitHub API post request will have the respective
option `maintainer_can_modify` option set.

This option was always enabled in fork mode before this commit,
and without fork mode enabled, the option is a noop because maintainers
have access to upstream branches regardless.

Users may want to leverage the option and disable it to avoid
issues with modifications in Renovate fork accounts, as described
in: renovatebot#19771

Fixes renovatebot#19771.
@devversion devversion changed the title fix(github): do not allow maintainer PR edits for fork PRs feat: add support for controlling whether PRs can be edited by maintainers Jan 24, 2023
@devversion
Copy link
Contributor Author

Thanks for the feedback. I've addressed it by introducing a new option. I will keep this a draft to iterate more on if this is what you expect. Would appreciate some early feedback. Thanks!

One note: I wasn't sure if this option should be "Github"-specific and reside in PlatformPrOptions. I've just made it a general PR create option similar to the draft-mode option. The option doesn't seem necessarily GitHub-specific. Happy to change though.

Copy link
Collaborator

@rarkins rarkins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This is only relevant to forkingRenovate. Right now it's configurable for both and the docs don't make it clear enough. Let's try to avoid confusing the 99% of users not affected by this
  2. Can this be made global config instead (i.e. controlled by the bot admin, not the repo admin)?

docs/usage/configuration-options.md Outdated Show resolved Hide resolved
docs/usage/configuration-options.md Outdated Show resolved Hide resolved
lib/config/options/index.ts Outdated Show resolved Hide resolved
docs/usage/configuration-options.md Outdated Show resolved Hide resolved
devversion added a commit to devversion/renovate that referenced this pull request Feb 2, 2023
This commit ensures the GitHub platform logic respects the
new `prallowMaintainerEdits` option.

Whenever a PR is created, depending on the option value,
the GitHub API post request will have the respective
option `maintainer_can_modify` option set.

This option was always enabled in fork mode before this commit,
and without fork mode enabled, the option is a noop because maintainers
have access to upstream branches regardless.

Users may want to leverage the option and disable it to avoid
issues with modifications in Renovate fork accounts, as described
in: renovatebot#19771

Fixes renovatebot#19771.
@devversion devversion requested review from HonkingGoose, rarkins and viceice and removed request for HonkingGoose, rarkins and viceice February 2, 2023 17:23
@devversion
Copy link
Contributor Author

I've addressed all feedback (and appreciate anybody having another look. Thanks for all the comments)

Github seems to just send it to one of the reviewers

lib/config/options/index.ts Outdated Show resolved Hide resolved
lib/modules/platform/github/index.ts Outdated Show resolved Hide resolved
devversion added a commit to devversion/renovate that referenced this pull request Feb 3, 2023
This commit ensures the GitHub platform logic respects the
new `prallowMaintainerEdits` option.

Whenever a PR is created, depending on the option value,
the GitHub API post request will have the respective
option `maintainer_can_modify` option set.

This option was always enabled in fork mode before this commit,
and without fork mode enabled, the option is a noop because maintainers
have access to upstream branches regardless.

Users may want to leverage the option and disable it to avoid
issues with modifications in Renovate fork accounts, as described
in: renovatebot#19771

Fixes renovatebot#19771.
devversion added a commit to devversion/renovate that referenced this pull request Feb 3, 2023
…oken` is set

This commit ensures the GitHub platform logic respects the
new `prallowMaintainerEdits` option when `forkToken` is set and
Renovate operates in a fork.

Whenever a PR is created with `forkToken` being set, depending on the
option value, the GitHub API post request will have the respective
option `maintainer_can_modify` option set.

This option was always enabled in fork mode before this commit,
and without fork mode enabled, the option is a noop because maintainers
have access to upstream branches regardless.

Users may want to leverage the option and disable it to avoid
issues with modifications in Renovate fork accounts, as described
in: renovatebot#19771

Fixes renovatebot#19771.
…rkToken`is set

Platforms like GitHub expose options to control whether
a PR can be modified by maintainers.

See e.g. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork

This commit introduces a way to control this in Renovate when Renovate
operates in a fork. The option will default to `true` for backwards
compatibility.

Users may use this option to workaround issues as outlined in: renovatebot#16657.
…oken` is set

This commit ensures the GitHub platform logic respects the
new `prallowMaintainerEdits` option when `forkToken` is set and
Renovate operates in a fork.

Whenever a PR is created with `forkToken` being set, depending on the
option value, the GitHub API post request will have the respective
option `maintainer_can_modify` option set.

This option was always enabled in fork mode before this commit,
and without fork mode enabled, the option is a noop because maintainers
have access to upstream branches regardless.

Users may want to leverage the option and disable it to avoid
issues with modifications in Renovate fork accounts, as described
in: renovatebot#19771

Fixes renovatebot#19771.
@devversion
Copy link
Contributor Author

I've incorporated all the docs suggestions and switched back to a repo config setting. A global option would simplify this a bit, but would make it impossible to use this option when e.g. the forking renovate GitHub app is used.

Sorry. I've also force-pushed to clean-up the commits which made it more difficult to review- a full review is easier in this situation anyway (and very likely needed anyway)

@devversion devversion requested review from viceice and removed request for rarkins February 3, 2023 14:44
@devversion
Copy link
Contributor Author

I'm good restricting the option name also to forkMode. Updated as per review suggestions. One extra note: I changed the createPr option from allowMaintainerEdits also to forkModeAllowMaintainerEdits because otherwise it would be quite ambiguous. We could even go further and move it into platform options I assume.

@devversion devversion requested a review from rarkins February 10, 2023 16:18
lib/modules/platform/github/index.spec.ts Outdated Show resolved Hide resolved
docs/usage/configuration-options.md Outdated Show resolved Hide resolved
docs/usage/configuration-options.md Show resolved Hide resolved
@devversion
Copy link
Contributor Author

FYI: I will wait with any docs changes until we have settled on runtime code, naming, or if this should be a global only flag etc.

@devversion devversion requested review from HonkingGoose and removed request for rarkins February 21, 2023 17:11
docs/usage/configuration-options.md Outdated Show resolved Hide resolved
docs/usage/configuration-options.md Outdated Show resolved Hide resolved
lib/config/options/index.ts Outdated Show resolved Hide resolved
lib/modules/platform/types.ts Outdated Show resolved Hide resolved
@viceice viceice requested a review from rarkins February 22, 2023 10:04
@viceice viceice enabled auto-merge February 22, 2023 10:05
@viceice viceice disabled auto-merge February 22, 2023 10:05
@viceice viceice changed the title feat: flag to control whether PRs can be edited by maintainers if forkTokenis set feat(platform/github): flag to control whether PRs can be edited by maintainers if forkTokenis set Feb 22, 2023
@viceice viceice enabled auto-merge February 22, 2023 10:05
Copy link
Collaborator

@HonkingGoose HonkingGoose left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about using a simpler name like forkModeBlockMaintainerEdits?

The word disallow feels clunky to me. I think a word like block is easier to understand.

I'll let the maintainers decide if they want to apply my suggestions.

docs/usage/configuration-options.md Show resolved Hide resolved
docs/usage/configuration-options.md Show resolved Hide resolved
docs/usage/configuration-options.md Show resolved Hide resolved
lib/config/options/index.ts Show resolved Hide resolved
lib/config/options/index.ts Show resolved Hide resolved
lib/modules/platform/github/index.spec.ts Show resolved Hide resolved
lib/modules/platform/github/index.spec.ts Show resolved Hide resolved
lib/modules/platform/github/index.ts Show resolved Hide resolved
lib/modules/platform/types.ts Show resolved Hide resolved
lib/workers/repository/update/pr/index.ts Show resolved Hide resolved
@devversion
Copy link
Contributor Author

Yeah, if the maintainers think they prefer block, I can make the change. I personally prefer (dis)allow since that is the terminology used by GitHub as well. Blocking feels different to me (but I'm a non-native speaker) See:

image

and https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork.

@viceice
Copy link
Member

viceice commented Feb 22, 2023

i think disallow is the right thing 🤷‍♂️

@HonkingGoose
Copy link
Collaborator

I personally prefer (dis)allow since that is the terminology used by GitHub as well.

Good point, let's stick with dis(allow) then. 😄

@HonkingGoose
Copy link
Collaborator

@viceice can you resolve my PR review comments? I can't do this myself: 1

You can resolve a conversation in a pull request if you opened the pull request or if you have write access to the repository where the pull request was opened.

Footnotes

  1. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews#resolving-conversations

@viceice viceice added this pull request to the merge queue Feb 22, 2023
Merged via the queue into renovatebot:main with commit 340a913 Feb 22, 2023
@renovate-release
Copy link
Collaborator

🎉 This PR is included in version 34.151.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fork mode: Previously edited branch does not get overridden/deleted
5 participants