Trouble Accessing Nested Maps in Taskfile Templates

[falconTwo]

Hi everyone,

I’m currently struggling with accessing values from nested maps in a Taskfile. Maybe someone can help me figure out what I’m doing wrong.

Taskfile

  version: '3.44.1'
  vars:
    BUILD_PROFILES:
      map:
        default:
          env: 'local'
          dockerfile: 'path/to/default/Dockerfile'
        test:
          env: 'test'
          dockerfile: 'path/to/test/Dockerfile'
  
  tasks:
    container-build:
      vars:
        profile: '{{.profile | default "default"}}'
        profile_config: '{{index .BUILD_PROFILES .profile}}'
      cmds:
        - cmd: 'echo {{.BUILD_PROFILES}}'
        - cmd: 'echo {{.profile_config}}'

Output
When I run the task, I get the following output:

map[default:map[dockerfile:path/to/default/Dockerfile env:local] test:map[dockerfile:path/to/test/Dockerfile env:test]]
map[dockerfile:path/to/default/Dockerfile env:local]

So far, so good — I can access the first-level map.

The Problem
Access through index
As soon as I try to access the nested values directly, I run into errors. For example:

...
- cmd: 'echo {{index .profile_config "env"}}'
...

This fails with:
task: Failed to run task "container-build": template: :1:7: executing "" at <index .profile_config "env">: error calling index: cannot index slice/array with type string

Access with get
And when I try with get:

...
- cmd: 'echo {{.profile_config | get "env"}}'`
...

This also fails with...
task: Failed to run task "test": template: :1:29: executing "" at <"env">: can't handle "env" for arg of type map[string]interface {}

Question

Why am I able to echo the nested map, but not access a specific key (like env) from it?
What’s the correct way to reference nested map values in Taskfile templates?

Any insights would be greatly appreciated!

[pd93]

Hey @falconTwo. Let's start with some debugging. It's often useful to use the spew function when trying to resolve issues like this as it gives a bit more information about what's going on:

    cmds:
-     - cmd: 'echo {{.BUILD_PROFILES}}'
-     - cmd: 'echo {{.profile_config}}'
+     - cmd: echo "{{spew .BUILD_PROFILES}}"
+     - cmd: echo "{{spew .profile_config}}"

The first line outputs your map variable as expected:

(map[string]interface {}) (len=2) {
 (string) (len=7) default: (map[string]interface {}) (len=2) {
  (string) (len=3) env: (string) (len=5) local,
  (string) (len=10) dockerfile: (string) (len=26) path/to/default/Dockerfile
 },
 (string) (len=4) test: (map[string]interface {}) (len=2) {
  (string) (len=3) env: (string) (len=4) test,
  (string) (len=10) dockerfile: (string) (len=23) path/to/test/Dockerfile
 }
}

However, you might be surprised that the second output is actually a string instead of a map:

(string) (len=52) map[dockerfile:path/to/default/Dockerfile env:local]

This isn't obvious because the output contains the word "map". However, the output of a template is always a string in Task. This is a limitation of the underlying templating engine from Golang. If the type being output is not a string, then it will be "stringified". That's what you're seeing here.

This scenario is exactly why we forked the Golang templating library and created the ref keyword. References will keep type information instead of stringifying. For example:

    vars:
-     profile: '{{.profile | default "default"}}'
-     profile_config: '{{index .BUILD_PROFILES .profile}}'
+     profile: '{{.profile | default "default"}}'
+     profile_config:
+       ref: "index .BUILD_PROFILES .profile"

This time, the second line will output your map type as intended:

(map[string]interface {}) (len=2) {
 (string) (len=3) env: (string) (len=5) local,
 (string) (len=10) dockerfile: (string) (len=26) path/to/default/Dockerfile
}

It's also worth noting that you can access map fields using dot notation (.BUILD_PROFILES.default.env etc). However, I understand that in this situation you need to use index or get since the map key is variable.

Hope that helps. Feel free to ask any follow-up questions.

[falconTwo]

@pd93 Thank you very much for taking the time to explain this in detail. It wasn't obvious. I can't ask for more 🙏🏻