Project Audit Events are full of "Added protected branch"

[gdubicki]

Probably because we unprotect and then protect branches again to perform some operations.

[nickshulba]

Hello Greg
Could you provide more details why Gitlabforms needs to do this protect/unprotect action against branch?
It caused my pipeline to fail turning off branch protection exactly when deploy started.
If this option is configurable, please give a hint. It would help me a lot if I could control this activity (or disable completely)

[sitnik]

This issue may actually break pipelines if they depend on protected variables and run at the same moment when protection was removed and not yet put back.
Why Renovate removes protection if nothing was changed in its and in repository configuration?

[gdubicki]

We do it to change the file values if you use the files configuration, for example. See https://github.com/egnyte/gitlabform/blob/main/gitlabform/gitlabform/processors/project/files_processor.py#L54-L59.

[YuraBeznos]

We do it to change the file values if you use the files configuration, for example

Another place is in the branch processor: https://github.com/egnyte/gitlabform/blob/main/gitlabform/gitlabform/processors/project/branches_processor.py#L13

[YuraBeznos]

Interesting place: https://github.com/egnyte/gitlabform/blob/9908247e66b5c6cac47d1c147dbb9235e8aebd7a/gitlabform/gitlabform/processors/util/branch_protector.py#L37

Is it really required to unprotect first to change those values?

[gdubicki]

Is it really required to unprotect first to change those values?

It was when I wrote that code.. Or I am not aware of some GitLab API feature? Something sudo-like? But was always using an admin token, so it should not be necessary..

[YuraBeznos]

Is it really required to unprotect first to change those values?

It was when I wrote that code.. Or I am not aware of some GitLab API feature? Something sudo-like? But was always using an admin token, so it should not be necessary..

Thanks! It looks like still required, but in most cases those settings are already set so this part in the code means lets rewrite the same thing which already set.

How about to check if settings are different first? I've tried to implement it via above MR but tests still require to be fixed.

[amimas]

How about to check if settings are different first?

It'd be great if we could do that. Otherwise I find the audit events are becoming too noisy; not to mention the potential of CI breaking due to protected variables not being available when this is happening.

[YuraBeznos]

As I can see this one is fixed in latest releases of 2.x .

[gdubicki]

Yes, it should be completely fixed in v2.0.2+. Please reopen if anyone is still seeing this issue after GitLabForm upgrade.

[gdubicki]

I am seeing this. :P

[robin-moss]

So am I, but not sure when this started happening again 🤔

[gdubicki]

This should finally be fixed in the next release, with the above PR, to be released in a day or two.