Repository navigation
Can't use computed lists in matrix loops #2544
Description
Description
You can only use literal lists in matrix loops, either by reference, or directly. Using a list created from some other source, fails.
See the example taskfile, where OS_KEYS is a list produced by the keys template command.
Output for task:
[spew] OS_VAR: ([]interface {}) (len=3 cap=3) {
[spew] (string) (len=7) "windows",
[spew] (string) (len=5) "linux",
[spew] (string) (len=6) "darwin"
[spew] }
[spew] OS_KEYS: ([]string) (len=3 cap=4) {
[spew] (string) (len=6) "darwin",
[spew] (string) (len=7) "windows",
[spew] (string) (len=5) "linux"
[spew] }
[list-ref] windows/amd64
[list-ref] windows/arm64
[list-ref] linux/amd64
[list-ref] linux/arm64
[list-ref] darwin/amd64
[list-ref] darwin/arm64
task: Failed to run task "default": task: Failed to parse /tmp/repro/Taskfile.yml:
matrix reference ".OS_KEYS" must resolve to a list
I do note that spew shows that the keys list a []string array, while OS_VAR is a []interface {} array, but I wouldn't expect that to be the issue.
Version
3.45.5
Operating system
macos 15.6.1
Experiments Enabled
No response
Example Taskfile
version: '3'
output: prefixed
vars:
OS_MAP:
map:
windows: "Microsoft Windows"
linux: "Linux kernel"
darwin: "Apple macos"
OS_VAR: ["windows", "linux", "darwin"]
OS_KEYS: { ref: keys .OS_MAP }
ARCH_VAR: ["amd64", "arm64"]
tasks:
spew:
silent: true
cmds:
- "echo -n 'OS_VAR: {{spew .OS_VAR}}'"
- "echo -n 'OS_KEYS: {{spew .OS_KEYS}}'"
list-ref:
silent: true
cmds:
- for:
matrix:
OS: { ref: .OS_VAR }
ARCH: { ref: .ARCH_VAR }
cmd: echo "{{.ITEM.OS}}/{{.ITEM.ARCH}}"
keys-output:
silent: true
cmds:
- for:
matrix:
OS: { ref: .OS_KEYS }
ARCH: { ref: .ARCH_VAR }
cmd: echo "{{.ITEM.OS}}/{{.ITEM.ARCH}}"
default:
cmds:
- task: spew
- task: list-ref
- task: keys-output
Activity
trulede commentedon Dec 5, 2025
Yeah, the type switch matches on
[]anybut you have a[]stringand so it does not match.task/variables.go
Line 419 in 2161f33
The solution might be to use reflection:
no-hup commentedon Aug 4, 2026
Ran into this too — the matrix ref path only accepts a literal
[]any, so anything computed via template functions likesplitList(which resolve to[]string) gets rejected even though it's a perfectly good list. I've got a small fix ready (type-switch mirroring whatitemsFromForalready accepts) plus tests; opening a PR shortly.