Allow date/time stamps in log records

[JoeBrunsTR]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Please search the existing issues for relevant feature requests, and use the
reaction feature
(https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)
to add upvotes to pre-existing requests.

Description

See https://discuss.hashicorp.com/t/date-time-stamps-in-packer-logs/71567/3

Keeping with the reply, a new plr.hcl config could be set (leave the default the way it is today) that would insert a date/time stamp to log records in any ISO8601 format I choose.

Use Case(s)

Example:

All packer releases up to and including 1.11.2.

Today we see:

amazon-ebs.windows: Completed - Exitcode is 0

tomorrow it would be ideal to see:

2024-11-25T15:04:07Z-amazon-ebs.windows: Completed - Exitcode is 0

This would retain the current component name but insert a date/time stamp in front.

Up to you guys what ISO8601 formats you will allow but one that shows UTC date/time is very helpful.

Potential configuration

Potential References

[JoeBrunsTR]

In essence, you would permit:

date/time component message

[JoeBrunsTR]

Perhaps a config that might look like:

logtimedate = true
logtimedateformat = YYYY/MM/DDtHH:MM:SSz

logtimedateformat = YYYYMMDDtHHMMSSz ,- if slashes or colons are a bad idea

[lbajolet-hashicorp]

Hey @JoeBrunsTR,

Thanks for opening this issue!

As mentioned in the Discuss thread, I would not consider this part of the configuration for the build, but as a runtime option instead, typically as an environment variable for now. I say for now since we are considering changes to the Packer configuration, so this would typically fit in this category.

Regardless, we don't need to wait until we've rolled-out those changes before we start thinking about this change, we'll discuss it internally and keep this issue updated.

[JoeBrunsTR]

However it can be made possible is fine with me.