Hi @exaV !

The first rule below is exactly that - Emphasis on is not '0':

* the `spec.refreshInterval` has passed and is not `0`

What made this documentation unclear to you when you read it?
IMO - we should add this to the rules session as opposed to a left out comment saying all rules are invalid, specially when thats not the case.

Thanks for the quick reply! The way the rules are currently written implies any of the three rules can trigger an update (independently of the other rules), but that does not happen in practice if refreshInterval is 0. I also wondered a bit at first if all three rules had to be met, but that would imply you'd have to change the ExternalSecret's spec for any change to take effect which is certainly not the case.

We could also change the wording to something like the following:

The `Kind=Secret` is updated when:

* the `spec.refreshInterval` has passed and is not `0`
* the `ExternalSecret`'s `labels` or `annotations` are changed and `spec.refreshInterval` is not `0`
* the `ExternalSecret`'s `spec` has been changed and `spec.refreshInterval` is not `0`

Or we could move it to the first sentence:

The `Kind=Secret` is updated when one of the following conditions is met and `spec.refreshInterval` is not `0`:

* the `spec.refreshInterval` has passed
* the `ExternalSecret`'s `labels` or `annotations` are changed
* the `ExternalSecret`'s `spec` has been changed

Or we could move it to the first sentence:

The Kind=Secret is updated when one of the following conditions is met and spec.refreshInterval is not 0:

• the spec.refreshInterval has passed
• the ExternalSecret's labels or annotations are changed
• the ExternalSecret's spec has been changed

I like that! let's do it! Thanks for your contribution

Thanks for your contribution!! 🙏🏾🙏🏾🙌🏾

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud