Confirm protected branch before running checks

What does this MR do?

In order to allow for a more targeted application of CodeOwner rules, I extracted the logic into Gitlab::CodeOwenrs::Validator (!32225 (merged) ) - great! The existing use case, in ee/lib/ee/gitlab/checks/diff_check.rb contained the checks for whether or not the target branch was a protected branch with codeowner checks enabled. This logic did not get extracted to the validator, so was missing when the validator was applied to the file edit. !33310 (merged) adds this logic to Gitlab::CodeOwenrs::Validator.

Closes #219340 (closed)

added customer devopscreate groupsource code priority1 reproduced on GitLab.com severity3 typebug labels

Tagging @garyh for an initial review

assigned to @garyh

approved this merge request

added 1 commit

• ab8747e1 - Confirm protected branch before running checks

Compare with previous version

added 1 commit

• 204ab72c - Confirm protected branch before running checks

Compare with previous version

added 10 commits

• 204ab72c...749354d3 - 9 commits from branch master
• 31c852ea - Confirm protected branch before running checks

Compare with previous version

mentioned in issue #219340 (closed)

changed the description

@rspeicher Have a moment for a maintainer review?

assigned to @rspeicher

approved this merge request

resolved all threads

@kerrizor @garyh LGTM, thanks!

merged

mentioned in commit 4f3da9a5

should we be labelling this Pick into auto-deploy ?

I believe so, based on https://about.gitlab.com/handbook/engineering/releases/#gitlabcom-releases-2 but I don't know if that's been updated to reflect daily deploys.

Regardless.. yes.

I don't believe we've completed updated documentation on our latest auto-deploy daily branch process. As this is now merged into master, a new auto-deploy branch will be created tonight, barring any issues, this should land in production tomorrow.

@skarbek for my education then, do we need to be adding the Pick into auto-deploy then, or we're good to go?

At this moment, for this specific MR, no. You're good to go on this one. We still have a few details to work out, but this label will still serve a purpose in times of dire need, such as an incident.

added Pick into auto-deploy label

@kerrizor This merge request could not automatically be picked into 13-1-auto-deploy-20200528 for 13.1.0-ee:

• Merge request does not have S1 or S2 label

This requires manual intervention.

Please refer to GitLab.com releases

removed Pick into auto-deploy label