Git branch protection rule is applied immediately

[devopssuren]

Problem Description

Git branch protection rule is applied immediately and hence unable to force merge certain automated merges

What is actually happening

i protect the branch in general with certain checks for general development using this safe-settings across all repos in my org, but in certain. scenarios, i am required to update the branch with force merge branch as well and as this would be blocked due to the active branch protection i call git api to delete the branch protection and then perform git push.
But in certain cases of huge branches before the git push the branch protection is enabled again immediately due to. which my git api branch protection deletion is also helping and failing to perform the force branch merges

What is the expected behavior

Can i have a wait_timer value set manually, for apply all settings if needed with a wait time for the consumer and have the default as the current case.

Context

Are you using the hosted instance of probot/settings or running your own? running my own

If running your own instance, are you using it with github.com or GitHub Enterprise? github enterprise

Version of probot/settings latest

Version of GitHub Enterprise latest and might not applicable for this reported problem

[PendaGTP]

@devopssuren If I understand correctly, this is more of a feature request to add an option to delay the sync of all settings and/or specific plugins (branches in this case). It would be helpful if you could update your issue or close this one and open a new one using the feature request template. Please let me know if I've misunderstood.

I think this would be quite complicated to implement properly, as it would likely require significant changes to how the synchronization system works.

I can suggest a potential workaround for your current needs:
Safe-Settings ignores webhook events when the sender is a Bot account, so if you make your API calls using a Bot account, the sync won't occur.

[devopssuren]

thanks @PendaGTP , will try this workaround and will raise this a a feature request as suggested.