Fixes #751 - A pod-culler bug

[consideRatio]

@betatim @minrk Sorry for causing this, this closes #751.

the helper jupyterhub.matchLabels will return labels based on the files parent directory (component: pod-culler), but that can be overridden if one passes the helper a scope containing a .componentLabel.

Note that the output will be:
component=singleuser-server,app=jupyterhub,release=prod
Instead of:
component=pod-culler,app=jupyterhub,release=prod

Using the app and release as selectors as well is done systematically on all pods according to helm chart best practices.

[betatim]

This is an example of calling the helper called jupyterhub.commonLabels with scope .?

[betatim]

acces -> access

[betatim]

A different way of saying this would be that an argument to the right overwrites an argument to the left of it? In this case if appLabel was also defined in the current scope we'd end up with the value from the current scope being available to the helper?

[consideRatio]

Yes I think so, but this will never be an issue I think, because I don't know how to add things to the current scope without doing it the other way around:

{{- $_ := merge . (dict "addedKey" "value1") }}

If one later execute the code below, I think you are correct in that the right dictionary (.) would override the left and make addedKey have "value1" instead of "value2".

{{- $_ := merge (dict "addedKey" "value2") . }}

But doing...

{{- $addedKey := "something" }}

Will not be accessible through .addedKey but instead $addedKey.

[betatim]

Used to by the -> Used by the
is outputted -> is output

[betatim]

Looks good to me. There are a few typos and some questions for my education.

When I read the comments before about scope I had assumed it was talking about things set in the template where the helper was being called. Somehow that confused me :)

[consideRatio]

@betatim thank you for helping me process this! I really appreciate it!

[betatim]

🎉 !