Versioning plugin-resolved files

[thsig]

Versioning plugin-resolved files

Garden allows plugins to resolve template strings.

This is used e.g. by kubernetes actions to resolve template strings in manifest files. The k8s-deploy-shared-manifests example project uses this pattern extensively.

In this project, the base hostname appears in the config of the web Deploy action:

# From examples/k8s-deploy-shared-manifests/web/garden.yml
variables:
  appName: web
  healthCheckPath: /
  replicas: 1

  env:
    - name: HOSTNAME
      value: ${variables.baseHostname}

This means that if the value of variables.baseHostname were to be edited in the project-level variables declaration, the action version would change. Therefore, a subsequent garden deploy would redeploy as expected.

However, if ${variables.baseHostname} were to appear directly in the manifest file (but nowhere in the action config itself), editing the value would not result in a redeploy.

This is because neither the action config nor the manifest files on disk (which have unresolved Garden template strings in them) would change when the project variable is edited.

How to proceed

I think we should do one of the following:

1. Clearly document this: Make sure that all template variables you reference in your actions' manifests also appear in your action configs (e.g. under their variables field).
2. Add a plugin handler where the plugin can return "additional resolved files" to include in the action version calculation (this handler would be called in ResolveActionTask's process method).

Option 2 kind of feels like overkill to me, but I'm just wondering how counterintuitive this might be to users.

I'd sort of expect Garden to detect changes to resolved template strings everywhere I use them, and to at least be warned clearly about any exceptions to that general rule.

What are your thoughts on all this?

[stefreak]

@shumailxyz @thsig I think it is important that Garden does the right thing and correctly identifies that the action needs to be re-deployed when I change variables in a manifest.

I think the handler should return additional references to variables, instead of additional files, because if the files were e.g. YAML files, we'd need to parse the YAML before finding all the referenced template variables, and because the framework should be agnostic of the file format, finding the references needs to be done in the plugin.