Thank you for maintaining this great tool. We use ecschedule extensively for managing ECS scheduled tasks.
Issue
Using {{ tfstate }} in top-level cluster or role fails with tfstate reference ... is not defined since v0.14.0. Works fine in v0.13.1. Using {{ tfstate }} inside rule fields (e.g. taskDefinition) is not affected.
Minimal reproduction
ecschedule.yaml:
region: ap-northeast-1
cluster: "{{ tfstate `output.system_info.service_name` }}"
rules:
- name: test
scheduleExpression: "cron(0 * * * ? *)"
taskDefinition: sometask
launch_type: "FARGATE"
plugins:
- name: tfstate
config:
path: "terraform.tfstate"
Result:
$ ecschedule -conf ecschedule.yaml apply -rule test -dry-run
[ecschedule] 💢 tfstate reference `output.system_info.service_name` is not defined
What I verified
- v0.13.1: works
- v0.14.0 / v0.17.2: fails
- Hardcoded cluster + tfstate in rule fields: works on v0.17.2
- tfstate-lookup v1.8.0 CLI standalone resolves the same key correctly
- The error comes from
validateTFstate() in rule.go detecting an unresolved placeholder in the marshaled Rule
Possible cause
The only code difference between v0.13.1 and v0.14.0 is dependency updates (notably goccy/go-yaml v1.15.15 → v1.19.0). The application logic in config.go, plugin.go, and template.go is identical. The second yaml.Unmarshal in LoadConfig may not be overwriting *BaseConfig fields correctly with the newer go-yaml version.
Thank you for maintaining this great tool. We use ecschedule extensively for managing ECS scheduled tasks.
Issue
Using
{{ tfstate }}in top-levelclusterorrolefails withtfstate reference ... is not definedsince v0.14.0. Works fine in v0.13.1. Using{{ tfstate }}inside rule fields (e.g.taskDefinition) is not affected.Minimal reproduction
ecschedule.yaml:
Result:
What I verified
validateTFstate()in rule.go detecting an unresolved placeholder in the marshaled RulePossible cause
The only code difference between v0.13.1 and v0.14.0 is dependency updates (notably
goccy/go-yamlv1.15.15 → v1.19.0). The application logic in config.go, plugin.go, and template.go is identical. The secondyaml.UnmarshalinLoadConfigmay not be overwriting*BaseConfigfields correctly with the newer go-yaml version.