Shorthand for "current yaml path" in templating

[crwr45]

A very common pattern with this approach is to have an entry in the template that resolves to the value at the same YAML path in the document being compared. This is repetitive and therefore a potential source of error, particularly with longer paths or more complex documents.

Example:

For the document:

spec:
  template:
    metadata:
      name: ThisNameCanBeAnything

the current template would have to look like:

spec:
  template:
    metadata:
      name: {{ .spec.template.metadata.name }}

If there were to be a shorthand for this operation it could look like:

spec:
  template:
    metadata:
      name: {{ anything() }}

Consider this a discussion of:

• is it possible and worthwhile to include a shorthand for "replace this with the value from the same yaml path"?
• is this worth implementing only for trivial cases (i.e. only when the full path already exists in the template)?

[crwr45]

My initial thought is that this would be too complex if all cases are supported. In order to reliably figure out the yaml path from the template the rest of the template would have to have been rendered, necessitating a two-stage rendering process and/or some form of lazy evaluation in the helper. This may not be possible where loops and conditionals are concerned without invasive changes in the templating engine. However, I do think this would be a considerable improvement to readability and usability of the templates if this is possible, even if only for the cases where embedded logic does not affect the yaml path.

[pixelsoccupied]

too complex if all cases are supported

Yep agreed. Unless you're talking about specifically the name? i.e a template function that would map to .spec.template.metadata.name --> getname() implemented with go (.eg see /compare/funcmap.go).

But generally we should try to be a little prudent when comes to adding custom functions in the code base and when we do...it should super general purpose IMO (of course exception apply but hopefully not many)

And tbh .spec.template.metadata.name and it's just cleaner to understand + for user...one less thing to remember and decide whether or not to use getname() when initially creating the references with the template rules?

[nocturnalastro]

I think using the merges would make this no longer required as you could just leave it out completely.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[nocturnalastro]

/lifecycle frozen

[lack]

The new regex inline diff functionality may make this easier to represent in templates:

spec:
  template:
    metadata:
      name: ".*"

The additional cost of this approach is that you would need to mark that field as a regex in the metadata.yaml:

apiVersion: v2
parts:
- name: ExamplePart
  components:
  - name: Example
    allOf:
    - path: that-template.yaml
      config:
        perField:
        - pathToKey: spec.template.metadata.name
          inlineDiffFunc: regex