Skip to content

Automatically invalidate PR approvals in case of new commits #9016

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.

Sign up for GitHub

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

Jump to bottom
Closed
1 task done
manuelmohr opened this issue Nov 15, 2019 · 1 comment
Closed
1 task done

Automatically invalidate PR approvals in case of new commits #9016

manuelmohr opened this issue Nov 15, 2019 · 1 comment
Labels
issue/duplicate The issue has already been reported.

Comments

@manuelmohr
Copy link

  • Gitea version (or commit ref): 1.10.0
  • Git version: 2.17.1
  • Operating system: Ubuntu 18.04.3 LTS
  • Can you reproduce the bug at https://try.gitea.io:
    • Not relevant

Description

Once a pull request has been approved, additional commits can be added to the pull request (potentially completely changing the proposed change) but the approving review stays valid.

While this makes it easy to sneak in minor fixes after a review without going through another review round, for some projects this poses an unacceptable risk.

Example:

  • Junior developer creates PR.
  • Senior developer reviews and approves.
  • Junior developer adds another "innocent" commit that actually introduces a bug.
  • Pull request is merged as it has an approving review.
  • There's now a bug in the software.

I propose to add an option in the style of Github (see below) to enable automatic invalidation of approvals as soon as the PR is changed.

Screenshots

image
@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Nov 15, 2019
@davidsvantesson
Copy link
Contributor

Duplicate of #5997.

@lunny lunny added issue/duplicate The issue has already been reported. and removed type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Nov 15, 2019
@lunny lunny closed this as completed Nov 15, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
issue/duplicate The issue has already been reported.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lunny @davidsvantesson @manuelmohr