Fix enqueing the same revision while reconciling

[matheuscscp]

Fixes: #1429

We traced the behavior reported in the issue back to the enqueue functions: they skip enqueue when the object is Ready=True and the revision matches. This should also happen if Reconciling=True. This check works because the object is patched with the attempted revision on the beginning of the reconciliation. Note that there's still a (very) small window where the object is not patched yet in which the issue can still happen.

[hiddeco]

Redundant with the predicate. If the source hasn't finished reconciling its latest generation, it also hasn't produced a new artifact yet, so helm-controller would just use the existing artifact (which is fine).

From the top of my head, this was put in place to ensure an update of e.g. the chart version in combination with a new set of values (especially when making use of a chart template) would not result in an upgrade with the old chart and new values.

[matheuscscp]

@hiddeco I restored the observed generation check, please take another look 🙏

[hiddeco]

@matheuscscp in the middle of moving this week so I won't have proper time until next week.

If you end-to-end confirmed this to not cause issues, I trust your judgement.

[matheuscscp]

@hiddeco No worries, there's a bug in upstream Helm that is staged for 4.1.2 next Wednesday. A Flux patch release is scheduled for the day after. I already did some testing and will do more in any case, but if by the release you have time for another peek it would be most welcome 🙏

[stefanprodan]

LGTM 🚀

[fluxcdbot]

Successfully created backport PR for release/v1.5.x:

• [release/v1.5.x] Fix enqueing the same revision while reconciling #1435