Skip to content

Don't reset approvals after rebase from UI

Rebasing from the UI should be considered a 'safe' action, so this should ignore the 'reset approvals on push' project setting.

Unfortunately, as rebase is implemented by working directly on a copy of the repository and pushing (as it's not supported fully by libgit2), we can't detect this purely with information available to the PostReceive job. If we used commit metadata, the MR author could also add the same metadata and push without resetting approvals.

To work around this, add a new column to the MergeRequest model to store the SHA from the rebase action. (Ensure that this is set before pushing, to avoid a race condition!) Then, in PostReceive, don't reset approvals if the pushed SHA matches the SHA stored in the database.

Approval_reset

Closes #372 (closed).

@DouweM this was marked as 8.9 but I think it's a bit close to be adding Pick into Stable - what's the procedure for this? I'm open to changing this implementation; @vsizov and I discussed it this morning and this was the simplest solution we came up with.

Merge request reports