Unversioned config keys
# 💻|contributing
s
Starting a thread on the "unversioned config keys" feature we were talking about yesterday 🧶
a
Thanks. I am currently building a proof of concept where we can ignore certain keys for action version calculation.
s
Initially, maybe it would make sense to just have this be a config field on actions (not on the spec, but a framework-level field on action configs). It would also simplify things to not allow template strings in this field (i.e. the config paths to ignore should be hardcoded). The config might look something like this:
Copy code
kind: Deploy
name: api
noCache: [
  ["spec", "someKey", "hostName"]
]
spec:
  someKey:
    hostName: "${var.baseUrl}/api" # <--- omitted before hashing
  ...
... actually, looks like we can allow template strings without problems (would be nice to e.g. be able to read this from a var). Just like the other top-level action fields (which use
ActionConfigContext
, but don't have access to everything that the spec has).
a
Another option i was thinking to mention the variables in
noCache
instead of full paths of keys and then we keep track of all the keys whose value have a template string with matching variable. Something like
Copy code
kind: Deploy
name: api
noCache:
 - var,baseUrl
spec:
  someKey:
    hostName: "${var.baseUrl}/api" # <--- omitted before hashing
  ...
Pushed a commit with a PoC. Tested on the quickstart example and currently the variable to ignore is hard coded as
Copy code
const ignoreVars = ["base-hostname"]
https://github.com/garden-io/garden/pull/5237/commits/1ded5f05a4bd9d2f372c701ee7a84a06d9ff5cac
The result of above looks like this
Copy code
deploy.api - ignoredKeys: [ 'spec.ingresses.0.hostname' ]
deploy.vote - ignoredKeys: [ 'spec.ingresses.0.hostname', 'spec.env.HOSTNAME' ]
s
Aha yeah, I think this sort of string query format makes sense.