You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using the amazon-ebs builder with the amazon-ami data source, to build a custom AMI based off an existing upstream AMI.
I've found that I can't run packer validate if I set deprecate_at to anything other than a literal string. My upstream AMI is replaced on a schedule, so I wanted to set deprecate_at to e.g. timeadd(data.amazon-ami.source.creation_date, duration). But when I do, I get an error like the following:
Error: 1 error(s) occurred:
* deprecate_at is not a valid time. Expect time format: YYYY-MM-DDTHH:MM:SSZ
I think this is a bug:
If I cause the result to be written to a file instead, I see that the written date/time matches the expected format.
If I replace timeadd(...) with the value written to the file, it validates.
If I replace timeadd(data.amazon-ami...) with timeadd(timestamp(), ...), it validates.
If I just run packer build example.pkr.hcl it works fine, setting the expected deprecation time.
This blocks me because my CI routine runs packer validate on the template, so even though packer build would work, CI fails. I would have to work around it by calculating the deprecation_time outside Packer and passing the result in as a variable.
Maybe this is a Packer problem? The data source is not evaluated by packer validate, and the parameter expects a particularly-formatted string, so there would be no way to ensure a calculated value is valid. I wonder if, instead of failing to validate, this could issue a warning instead?
Looks like formatdate may help you there? Have you tried something like formatdate("YYYY-MM-DDTHH:MM:SSZ", timeadd(data.amazon-ami.source.creation_date, duration))? This will format the timestamp returned by timeadd to the format that the attribute expects.
The data source is not evaluated during validate unless you use the -evaluate-datasources flag indeed, but the configuration is still validated (there are two passes for most entities, Prepare/Validate, and Run/Execute), packer validate will run the prepare step, which ensures the values are valid.
Regarding "Can it be a warning instead of an error", this may be possible, but I would advise against it, as the attribute is expected to be a date formatted exactly as it is, so if a user provides a misformatted date, I believe it is best that the plugin fails as quickly as possible instead of going into undefined behaviour territory. Especially if running in CI, warnings are easily missed, whereas errors will fail the build, prompting some investigation.
Note: scratch all that, I misunderstood the question, but the information may still interest someone who stumbles on this thread.
If I understand correctly here, the problem stems from the datasource not being evaluated, and the value being checked during validate, which is somewhat expected then. Plugins don't know if we're running validate/build, therefore they assume they're receiving a complete configuration to run a build with, hence the error here.
In your case for those CI runs, I would suggest maybe using the --evaluate-datasources flag when invoking packer validate, this way your datasource should be able to return valid values. This does have the drawback of potentally having a cost if the requests are billed
Overview of the Issue
I am using the
amazon-ebs
builder with theamazon-ami
data source, to build a custom AMI based off an existing upstream AMI.I've found that I can't run
packer validate
if I setdeprecate_at
to anything other than a literal string. My upstream AMI is replaced on a schedule, so I wanted to setdeprecate_at
to e.g.timeadd(data.amazon-ami.source.creation_date, duration)
. But when I do, I get an error like the following:I think this is a bug:
timeadd(...)
with the value written to the file, it validates.timeadd(data.amazon-ami...)
withtimeadd(timestamp(), ...)
, it validates.packer build example.pkr.hcl
it works fine, setting the expected deprecation time.This blocks me because my CI routine runs
packer validate
on the template, so even thoughpacker build
would work, CI fails. I would have to work around it by calculating the deprecation_time outside Packer and passing the result in as a variable.Maybe this is a Packer problem? The data source is not evaluated by
packer validate
, and the parameter expects a particularly-formatted string, so there would be no way to ensure a calculated value is valid. I wonder if, instead of failing to validate, this could issue a warning instead?Reproduction Steps
See gist at https://gist.github.com/saxonww/d237f1ff2a3292cf916b02d85eca8cb5
Plugin and Packer version
Packer v1.10.1
Plugin version v1.3.2
Simplified Packer Buildfile
See gist at https://gist.github.com/saxonww/d237f1ff2a3292cf916b02d85eca8cb5
Operating system and Environment details
A Docker container based on the following:
Architecture is x86_64.
Log Fragments and crash.log files
Setting PACKER_LOG=1 doesn't yield anything useful.
The text was updated successfully, but these errors were encountered: