allow templating in .gomplateignore, so folder can be dynamically excluded by configs

[thesuperzapper]

I was looking for a way to optionally exclude sub-folders of my --input-dir= depending on the values of specific data source configs.

If this is not already possible with some other method, could we consider enabling {{ templates inside the .gomplateignore files?

[hairyhenderson]

Hi @thesuperzapper, thanks for the suggestion.

In theory you could do this in a two-phase approach - first generate the .gomplateignore file, then do the rest.

If that doesn't work for you, please let me know more detail on how you think this could work, and what sort of benefit it would have.

[thesuperzapper]

@hairyhenderson In my specific case, it would be quite problematic to do a two-phase approach.

The general case where it's useful to template the .gomplateignore file are ones where you have a folder with many nested template files that you want to render, but also allow a config to exclude certain template sub-folder from being generated at all.

For example, if you have the following --input-dir template folder structure:

templates/
  folder_1/
    file_1.yaml
  folder_2/
    file_2.yaml
  .gomplateignore

You might want to provide a --context Values=my-values.yaml file that looks like this:

folder_1:
  enabled: false

folder_2:
  enabled: true

With the content of templates/.gomplateignore like this:

{{- if not .Values.folder_1.enabled }}
folder_1/
{{- end }}

{{- if not .Values.folder_2.enabled }}
folder_2/
{{- end }}

## prevent `.gomplateignore` from being rendered in the output
.gomplateignore

Which would produce an --output-dir folder structure like this:

folder_2/
  file_2.yaml

[hairyhenderson]

Hrm... With this particular example it seems simpler to just run with two separate --input-dir variables, no?

$ gomplate --input-dir=templates/folder_2/ --output-dir=out/folder_2/

The intent of the .gomplateignore file is to act just like the .gitignore file. I'm not keen on extending the format beyond that, as it would add considerable cognitive overhead...

[thesuperzapper]

Is it currently possible to invoke gomplate with multiple --input-dir, or were you suggesting a future idea?

Also, my example is intentionally simplified, you could have much more complex conditions in the situation where you want to treat a single --input-dir as a model for your directory, but prune specific files/folders from the output directory based on conditions.

I appreciate the complexity of supporting templates in the .gomplateignore, perhaps part of simplifying this is having a --templated-ignore flag which defaults to false, to prevent users who don't want this functionality from having to escape delimiter characters.

Alternatively, as you said, a user could set up a two-phase approach, but with the "model for your directory" use case described above, they would probably need to use a different delimiter for the first (.gomplateignore rendering) phase, which gets a bit messy.

[hairyhenderson]

Is it currently possible to invoke gomplate with multiple --input-dir, or were you suggesting a future idea?

No, sorry - I meant invoking gomplate twice.

What you're talking about sounds similar to what was discussed a few years back in #589 - maybe some of the concepts discussed there could be applied to what you're looking for?

Another approach could be to just use multiple .gomplateignore files, and/or multiple config files.

Ultimately, I want to be very careful not to add more complexity to gomplate without very strong reasons to do so (it's far too complex as it is!)

[thesuperzapper]

@hairyhenderson for now, in deployKF (which uses gomplate internally), I am just going to invoke the render twice:

1. first to ONLY render files from the input called .gomplateignore_template into .gomplateignore in the --input-dir
2. second, to actually render the input directory into an output folder

I will be interested to see if any other possible solutions crop up.

[hairyhenderson]

I think I'm understanding your use-case a bit better (from #1690).

I think what's probably ideal in your case is to simply not use the .gomplateignore functionality at all, and instead to walk your input directory in whatever way makes the most sense (implementing the ignore functionality in code) to populate the input []gomplate.Template for RenderTemplates.

How does that sound?

[thesuperzapper]

@hairyhenderson I am trying to keep my "source" templates as a self-contained artifact, and only use my CLI (which wraps the gomplate CLI) to render a given "source" for a provided values file.

For example, the following deploykf command will automatically download version v0.1.0 of the "source" and apply the user's custom ./custom-values.yaml to the default values from that source to create the ./GENERATOR_OUTPUT/ folder:

deploykf \
  --source-version=v0.1.0 \
  --values "./custom-values.yaml" \
  --output-dir "./GENERATOR_OUTPUT"

In your approach, I would have to make the deploykf CLI understand which conditions (combinations of values, for the specific version) imply which folders should be output, when all this complexity is contained in the source artifact using my two-phase .gomplateignore templating approach.

PS: I have already implemented the above example behavior in deploykf using gomplate through a fork that applies these two PRs

• fix reading templates in gomplate.RunTemplates() #1690
• expose SuppressEmpty in gomplate.Config #1691

[github-actions]

This issue is stale because it has been open for 60 days with no activity. Remove stale label or comment or this will be automatically closed in a few days.