Add .status.inventory to track managed objects

[cappyzawa]

Resolves: #1352

[hiddeco]

Wouldn't it be better to build this state through observations in the storage layer?

[matheuscscp]

Wouldn't it be better to build this state through observations in the storage layer?

Hi @hiddeco! You raise an excellent point here, that was my recommendation as well. I was told that doing this through storage observations would be more reliable. I have a gut feeling that this is accurate, but I don't have the precise explanation. Could you please shed some light on the details of why this is more reliable? (I'm guessing that the explanation is a one-liner but I can't get it together myself)

[cappyzawa]

@matheuscscp You did mention using storage.ObserveFunc in your initial guidance - I apologize for losing track of that recommendation as I progressed through the implementation.

@hiddeco @matheuscscp You're both right. Using the storage layer would bring a similar pattern to kustomize-controller - building inventory at the point of persistence rather than fetching from Helm storage after the fact.

I'll rework the implementation to use ObserveFunc.

[cappyzawa]

Thanks for the great feedback! I've addressed the suggestions in 7d3fa01:

• Removed buildInventory() from atomic_release.go and reimplemented as observeInventory() in release.go
• Uses storage.ObserveFunc pattern to build inventory when the release is persisted to storage
• Install/Upgrade/Rollback call observeInventory, Uninstall clears the inventory
• Emits warning event on error (no log, following existing patterns in the reconcile package)
• Added inventory assertions to install_test.go, upgrade_test.go, uninstall_test.go

[matheuscscp]

Great iteration!

[stefanprodan]

Please add a section to the API docs for the inventory after https://github.com/fluxcd/helm-controller/blob/main/docs/spec/v2/helmreleases.md#history

[matheuscscp]

LGTM! 🚀

Please squash for the merge 😁