Fixing templating vars inside range context

[omesser]

Inside .range context for vars changes, we need $ to refer to top level (for .Release or .Values)

[jesper7]

Also, let's leave out bugfix in the PR title. Otherwise, it gets duplicated in the changelog 🙂

[omesser]

Also, let's leave out bugfix in the PR title. Otherwise, it gets duplicated in the changelog 🙂

Hmm, Goes against most PR titling practices I've ever seen actually in any public (or private repo). There's usually some prefix convention (fix, bugfix, chore, feat, something..)
So something to think about I believe -
It's coming from keeping the commit log readable - I think the git history is probably more important then possible duplication of the word on the release changelog 🤔 . Also changelog sections might not correspond to this internal classification of change requests.

[jesper7]

Hmm, Goes against most PR titling practices I've ever seen actually in any public (or private repo). There's usually some prefix convention (fix, bugfix, chore, feat, something..)

I've seen thousands of projects not using any prefixes or annotations in their PR titles and commit messages.

Anyway, it would be nice to introduce prefixes or Conventional Commits. We've tried to set up the latter but ran into some issues. The difficulty lies in ensuring that every contributor's commits conform to the standard, hence the need for additional safeguards like pre-commit and CI jobs. Let's follow up here #50

[omesser]

@jesper7 - standardization aside, not sure I'm on the same page wrt Bugfix - prefix being detrimental (even if not standardized, as long as there's no OTHER standard).
However - this is a minor peeve. title changed - I'd like to commit all the helm changes so I can test them asap

fixed

[omesser]

Not relevant anymore - range loop removed