amimas

Btw, another reason for not using `enforce` key is to keep the option open so that in future enforce will work the same way as other processors - remove branch...

Do you agree with the enforce key behavior I mentioned above? If yes, let's update the original post to clarify the feature request. It's supported by other processors and could...

@jccl - interesting case. Does it mean the issue is only happening after the branch processor being migrated to `python-gitlab`, or is that just an observation? Regardless of how gitlabform...

Thanks @jccl for the additional context. I dug into the old code a little bit. The logic of "unprotect first and then protect again" existed before version `4.0.2` as you...

I suggest we keep it open until the PR has been merged.

Thanks for reporting @philippe-granet . I don't think there's a logic in the branch protection processor to check if repository is enabled or not. Can you contribute a fix? The...

Hi @gosoly - Could you please clarify or post the full config? It was kind of hard to follow the issue you described. I'll try to rephrase it below and...

> Isn't the `merge_requests_approval_rules:inherit: false` on `viator/infrastructure/*` just break inheritance from `viator/*` ? Yes, I think so. But, your config sample didn't show what's setup for `viator/*`. That's why I...

@gosoly - Thanks for sharing the config. I tried to reproduce the issue but couldn't. Here's what I tried. The following config shows 1 group with a nested config breaking...

@gosoly - Did you get a chance to review my finding? Are you using `skip_group`? Regardless, I think it's worth discussing it a bit more. > If you also have...