Closed timblaktu closed 3 years ago
Hey @timblaktu ! Thanks for opening, I agree with you there that the docs on configuring packer were a bit scarce, this recently changed for our coming release, along with a bunch of things. Though we didn't add anything around caching there, so I opened #10568 to add a blob of text about that. You can check everything out there: https://packer-2q2jaol6a.vercel.app/docs/configure#packer-s-cache-directory
Also it's not currently possible to set the cache dir from somewhere else than env vars; do you have a feature request about that ? Thanks !
Your new docs look great, thanks @azr. I haven't added a request for setting cache dir from config file, but I will think about creating one, not specifically for PACKER_CACHE_DIR but for ALL env vars to be settable via .packerconfig.
I will think about creating one, [...] for ALL env vars to be settable via .packerconfig.
That sounds like a good idea ! I wonder if it would be nice also to be able to set these directly from an HCL2 config file too ( so one in a global config and one in a more local config:
packer {
cache_dir = "..."
plugin_port_range = [ 10000, 25000 ]
// ......
Closing this issue as it will be solved during our next release ! Thanks for opening !
linking the related PR: https://github.com/hashicorp/packer/pull/10588#pullrequestreview-585370654
@azr you implied that adding support for setting all PACKER env variables through configuration file (and/or HCL2 file) was in the works. Is there yet a PR or changeset/branch that implements this? I noticed the PR #10588 linked by @SwampDragons above is related but different, just an env var name change.
As this issue is closed, I was just wanting some clarification about how/where/when this will be implemented.. Thanks. Let me know how I can help (testing, reviewing docs changes..)
Hey @timblaktu, just for clarification :
@azr you implied that adding support for setting all PACKER env variables through configuration file (and/or HCL2 file) was in the works.
I didn't mean that, sorry. I meant that this current issue (#10561) is fixed because you confirmed that the docs look great, so it can be closed. Nothing is in the works yet for that; our upcoming release is coming soon and it certainly feels like it has enough features 🙂 !
In my previous message (https://github.com/hashicorp/packer/issues/10561#issuecomment-775133729) I was thinking out loud to pick everyone's brain. Do you think this would be a good idea ? Would you like to open a new feature request issue describing it and sort of the why it makes your life better ?
I think your use case will be interesting to read as currently my thinking is that since Packer is mainly ran in CI mode it's easier and makes files simpler to sort of only allow setting those from ENV variables.
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
The docs on Core Configuration describe where packer looks for the configuration file, but it does not describe what it's contents should be, aside from saying "The format of the configuration file is basic JSON." This is not enough. A simple example should be posted on that page, showing what the structure of this JSON file looks like.
I have searched issues here, hashi discuss, and all of github for ".packerconfig" examples and have come up empty. So I will now just start making assumptions, like one always does in the absense of information, and take a stab at a flat JSON file.
Also, the configuration reference section seems woefully incomplete.
...Unless, "core configuration" and "environment variables" are completely distinct. I had assumed that I could set things like
PACKER_CACHE_DIR
in the "configuration file", so as to not clutter myJenkinsfiles
or.profiles
. If this is not the case, I would recommend a more explicit statement clarifying this in the above-linked doc pages.