branchprotector: remove protection from excluded branches

[kaovilai]

Fix issue where excluded branches retain existing protection instead of being removed.

When a branch is added to the exclude list in branchprotector configuration, the tool
correctly stops applying new protection rules but does not remove existing protection
from branches that were previously protected.

This change adds logic to detect excluded branches that are currently protected and
queue them for removal by sending requirements with Request: nil, which triggers
RemoveBranchProtection() in the configureBranches() function.

The fix prevents push failures like:
remote: error: GH006: Protected branch update failed for refs/heads/konflux-branch
remote: - Changes must be made through a pull request.

Changes:

• Add detection logic for excluded protected branches in UpdateRepo()
• Send removal requests (Request: nil) for such branches
• Update tests to expect removal requests for excluded protected branches
• Add code comment explaining the call flow to RemoveBranchProtection

Fixes #477

[netlify]

✅ Deploy Preview for k8s-prow ready!

Name	Link
🔨 Latest commit	f1b83a2
🔍 Latest deploy log	https://app.netlify.com/projects/k8s-prow/deploys/685018916d61cf000879fd38
😎 Deploy Preview	https://deploy-preview-478--k8s-prow.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

Hi @kaovilai. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kaovilai
Once this PR has been reviewed and has the lgtm label, please assign petr-muller for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[petr-muller]

/ok-to-test

[Prucek]

Why is this map needed?

[kaovilai]

Problem

The allBranches slice can contain duplicate entries for the same branch because it's populated from two separate API calls:

  for _, onlyProtected := range []bool{false, true} { // runs twice
      bs, err := p.client.GetBranches(orgName, repoName, onlyProtected)
      allBranches = append(allBranches, bs...) // can add same branch twice
  }

Without Deduplication

If a branch like konflux-test appears in both API responses, we would send two removal requests:

1. First iteration: {Org: "org", Repo: "repo", Branch: "konflux-test", Request: nil}
2. Second iteration: {Org: "org", Repo: "repo", Branch: "konflux-test", Request: nil}

With seen Map

  if b.Protected && branchExclusions.MatchString(b.Name) && !seen[b.Name] {
      seen[b.Name] = true  // Mark as processed
      // Send removal request only once
  }

The seen map ensures each excluded protected branch gets exactly one removal request, regardless of how many times it appears in allBranches.

This prevents:

• Duplicate API calls to GitHub
• Confusing log messages
• Potential race conditions in the removal process

[kaovilai]

Perhaps if p.client.GetBranches(orgName, repoName, false) return all branches we can initialize allBranches once.

[Prucek]

okay, get it. Thanks!

[Prucek]

/lgtm

[smg247]

Won't this remove protection from these branches that has been set up outside of prow? Historically, this has not been something that we have wanted Prow to do. I am concerned that this change is overreaching.

[kaovilai]

Prow already undid branch protections from my prior repos setups with branchprotector. It overrides native protection settings for all mentioned branches.. hence I had to set up my repos branch protections in prow.. and now that we added exclusion patterns to prow, prow do not remove them. And it's very annoying for working in openshift org because one can't just be admin all the time and undo these settings manually.

[smg247]

The concern I have here is that Prow will continue to remove the BP rules when the branch is listed as an exclusion. The problem you are describing requires an admin to go in and change something once, but if we add this logic there will be no possible way to set a BP rule outside of Prow for an excluded branch without Prow continually overwriting it.

[kaovilai]

will be no possible way to set a BP rule outside of Prow

That was already the case for my repo.. we had setup required approvals: 2 outside of prow

Then branchprotector undos them until we put it into the branchprotector yaml config.

[kaovilai]

https://redhat-internal.slack.com/archives/C0144ECKUJ0/p1688754465575399
openshift/release#41066

Perhaps it's because we had prow branch-protection configured for allow_force_pushes for something else and it just kept overriding everything else not mentioned as false/disabled.

Perhaps prow should only update fields that are explicitly mentioned.. ie. if true do this if false do this, if empty, do nothing.

[smg247]

Perhaps prow should only update fields that are explicitly mentioned.. ie. if true do this if false do this, if empty, do nothing.

IMO, this would be ideal. I am curious of what other's thoughts are on this though.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kaovilai]

/remove-lifecycle stale