docs: adding expose depoyed chart hip

[mrlunchbox777]

Adding a HIP to expose the currently deployed chart at render time.

[mrlunchbox777]

@scottrigby @gjenkins8 here is the hip we talked about at contribfest

[danilo-patrucco]

+1

[mrlunchbox777]

Some notes that were brought up to improve the proposal were to:

1. Consider the various states that .Deployed chart could be in (failed/rollback/etc), what to collect/show (size/speed implications), and how to control/represent the various options
2. Add notes for the existing flux use case

[mrlunchbox777]

Some notes that were brought up to improve the proposal were to:

1. Consider the various states that .Deployed chart could be in (failed/rollback/etc), what to collect/show (size/speed implications), and how to control/represent the various options
2. Add notes for the existing flux use case

Here is an example of getting flux CRs to control if an upgrade job runs. It was part of this MR. It was used for a default name change on immutable resources by deleting them in a hook.

[scottrigby]

my main thought is, would you not also want to expose the values of helm history to check things like whether a previous release was successful?

Some thoughts about this: What about adding "History" key to the existing .Release built-in: .Release.History when a --release-history-depth flag is passed?

This could be a filtered version of the Release object that's currently stored in helm release secrets by default.

Agree that the full release object could cause performance issues. perhaps this could be mitigated by:

• any history might be best to opt-into with a flag (default history level 0 rather than 1 as currently proposed)
• including only a filtered subset of the release object, omitting potentially very large data like templates, manifest etc.

Not yet sure what security concerns adding the Release object would add that other built-ins don't already have (eg, .Values, .Files, etc). But good to consider here.

[mrlunchbox777]

Thank you for the thoughtful suggestions! .Release.History feels natural and being part of an existing path makes it that much easier to find and use. Pulling the wider set of data is certainly more useful, it may be worth considering letting the user control the filter and default most things to discarded by default. This keeps with the opt-in nature of this proposal. I agree defaulting to 0 is better for similar reasons.

One suggestion I have on top of this would be to ensure that the user's decisions are available to the templates at the same time. This enables a "negotiation" between the user and author, i.e. a chart author may need a depth of 2 to render a chart properly and error out if not given it, but it doesn't force the condition on the user, they must accept first. It could also enable helpful error messages, extend testing, and branching logic based on available history.

Example use case:

{{- if lt .Release.HistoryDepth 3 }}
  {{- fail "This chart requires --release-history-depth=3 for safe upgrades from v2.x" }}
{{- end }}

Proposed field: .Release.HistoryDepth (aligns with flag name)

This would be a simple integer value (0, 1, 2, etc.) always available in template context, similar to how .Release.Revision is currently available.

What do you think of that addition? Should we determine what things should be filtered by default as part of this?

Again, really appreciate the review. I'll update the HIP to use .Release.History and associated changes.