* hcl2template: pass user variable values to plugins as packer_user_variables (#13686)
HCL2 builds do not send the packer_user_variables config key to the
builder, provisioner and post-processor plugins. Legacy JSON builds
send this key (through CoreBuild.packerConfig()). Without the key, the
plugin SDK keeps interpolate.Context.UserVariables nil. Then the
template function {{ user "name" }} fails with 'error calling user:
test'. This failure occurs in each string that a plugin interpolates at
run time, for example the contents of the vagrant post-processor's
vagrantfile_template.
Add the function PackerConfig.userVariableValues(). This function
converts the input variable values to strings, equivalent to the legacy
user variables. The core sends the map at each plugin handoff point:
builder, provisioner, post-processor, and enforced provisioner.
The map does not contain the sensitive variables. A sensitive value
goes to a plugin only if the template refers to it explicitly. The map
does not contain values that are not primitive (lists, maps, objects).
Legacy user variables were always strings.
Co-authored-by: Claude Fable 5 <[email protected]>
* Dependency upgrade (#13689)
* go.mod version upgrade
* actions upgrade
* plugin-getter: install plugins from non-GitHub HTTP sources (#13691)
Packer can only install plugins from github.com, with
releases.hashicorp.com consulted first for HashiCorp-published plugins.
This has been a long-standing gap for air-gapped and policy-restricted
environments (#11164): the source address parser already accepts any
hostname, but both existing getters reject non-github.com sources at
install time.
Add a remote plugin getter that installs plugins from the host named in
a required_plugins source address. The host serves the directory
structure of releases.hashicorp.com under the source's path: an
index.json listing versions, and per version a SHA256SUMS file, the
zips it lists, and - when the zip names carry no plugin protocol
version - the version's manifest.json. A plugin published on
releases.hashicorp.com is therefore mirrored as a verbatim copy of its
tree, with every checksum file and signature upstream-authored. A
plugin published as GitHub release assets is mirrored by copying each
release's assets into a version directory, renaming their SHA256SUMS
file to the unprefixed convention with content unchanged, and writing
an index.json listing the versions. Both kinds of content can be
served side by side by one host.
Getter selection happens per source address: github.com sources keep
the release and github getters unchanged, while any other host is
served by the remote getter over HTTPS. Sources with three or more
components are supported, up to the existing 16-component limit, so
nested artifact-repository paths and hosts that embed the upstream
origin in their path all resolve.
Version discovery, constraint solving, checksum verification, and the
binary naming rules match the existing getters. The installed filename
is rebuilt from validated checksum-file fields and never taken from the
server's response, checksum entries matching neither known naming shape
are rejected rather than guessed at, and nothing the remote metadata
supplies is used to fetch from another origin or path. index.json
parsing is covered by fixtures captured from the live releases API, so
a format change there fails tests rather than user installs.
Closes#11164
* fix: update link to CONTRIBUTING.md for consistency with main branch
* Merge pull request #13701 from hashicorp/sanya-hashicorp/fix-vuln
Module Dependency update
* build(deps): bump google.golang.org/grpc (#13704)
Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.83.1 to 1.83.2.
- [Release notes](https://github.com/grpc/grpc-go/releases)
- [Commits](https://github.com/grpc/grpc-go/compare/v1.83.1...v1.83.2)
---
updated-dependencies:
- dependency-name: google.golang.org/grpc
dependency-version: 1.83.2
dependency-type: indirect
...
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* [COMPLIANCE] Add/Update Copyright Headers (#13699)
* [COMPLIANCE] Add/Update Copyright Headers
* make generate update
* make generate
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: sanya <[email protected]>
Co-authored-by: Sanya <[email protected]>
* Packer release 1.16.1 (#13705)
* Module upgrade (#13707)
---------
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: Erik Berg <[email protected]>
Co-authored-by: Claude Fable 5 <[email protected]>
Co-authored-by: Benjamin Holmes <[email protected]>
Co-authored-by: elomito <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
* bump golang.org/x/crypto to 0.43.0
CVE-2025-47913 GO-2025-4116
* fixed go.sum
* fixed multiple warnings that prevented test runs
* make generate
* fix lint errors, update linter version
* fix go vet issues
The acceptance tests for the HTTP datasource had a `Outputs` attribute
for checking the output of the command for a specific regexp pattern.
As pointed out, given the expectative nature of the attribute, naming it
`Outputs` did not make the intent clear, so we rename it to
`ExpectedOutputs` with this commit.
Since the expected error to look for in the output is compiled to a
regexp, the `[]` from the error message were interpreted as a set of
characters, which made the regexp not match the expected output from the
command.
So to avoid this problem, we escape them so they are expected verbatim
in the command output.
Some of the variables we create are flagged by our linters as
ineffective assignments, which makes sense as those are generally fed by
code below, so we don't need to use the declaration/assignation syntax
(:=) but instead can fall back to using var with a type to get the zero
value of the declared entity.
When a server returns a code that is not 200, we error in the current
state.
This is not conformant to the HTTP norm, as anything in the 2xx range is
considered a success, so the datasource should not error in this case.
Therefore, this commit fixes the condition in which we report an error,
so that anything in the 2xx range is now considered a success by the
datasource.
* Updating the license from MPL to Business Source License
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at https://hashi.co/license-faq, and details of the license at www.hashicorp.com/bsl.
* Update copyright file headers to BUSL-1.1
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
The `packer-image-iteration' datasource is an undocumented, and
unexported datasource, so it cannot be used by clients.
Since this is dead weight, we can remove it safely from the codebase.
This commit reorganises the code for both the registry/API and the
Orchestrator/Registry.
The main difference with the previous version is how stuff is exposed.
Now we only expose a Registry interface to the outside (previously named
Orchestrator), which has several implementations: null is the default,
and is returned if HCP is not enabled.
The other implementations being HCL/JSON, both private to the hcp
sub-package.
The api (previously `registry') is the set of functionality that
abstracts and calls the HCP API.
It was meant to be merged with the `hcp' package, but because of a
dependency loop with the datasources, both are separated for now.
* Add `component_type` optional field
to support specifying the exact build image when multiple images exist in the same provider and region for a given iteration
* update docs
* update docs
The comment was mentioning the name of an iteration Id, which is
conflicting.
This commit rephrases the comment to directly specify the ID of the
iteration.
In addition to the current way of specifying an image based on an
iteration on HCP Packer, which requires first declaring an iteration,
and then referencing it from the image to build, we add the capacity of
specifying a channel.
This alternative will get the iteration linked to the channel, and is
essentially a more convenient way to get an image's metadata from HCP
Packer.
This commit is essentially a backport from the Terraform HCP provider,
for consistency between the two tools.
Anurag Sharma
karthik P
Devashish
Lucas Bajolet
Henrik Gerdes
guoguangwu
Wilken Rivera
Shohei Maeda
teddylear
Adrien Delorme
Megan Marsh