Since we moved to go 1.18, we should bump golangci-lint to a version
that supports it.
This change is motivated by the fact that some valid go code was being
rejected by the `typecheck` with aliased modules beign unrecognised,
namely the `hcl' module, imported from `hcl/v2'.
This should not cause any issues as the typechecker should be aware that
the package exported by `hcl/v2' is indeed called `hcl', but for some
reason, with version 0.42.0, it does not work.
This change updates Packer core Go version to 1.18. The move to Go 1.18 and not Go 1.19
is to allow the HCP Packer SDK time to upgrade to Go 1.18.
Changes Made:
* Bump go mod file to use Go 1.18
* Bump release pipeline to use Go 1.18
* Update plugin updater script to run go mod tidy for Go 1.18
* Update Linux job to use setup-go action
Before this commit, some HCP-related logic was embedded in the parser,
making all of it common to all commands.
This complexifies the logic as some parts rely on the template being in
a HCP-valid environment, and the datasources need to be evaluated in
order for some operations to be executed.
To simplify this and avoid those pitfalls, we move this logic to its own
set of functions that will be performed after the parsing is done, on
any valid HCL2 or JSON template.
Since the GetConfig methods are common to all the commands of Packer
that rely on a config to work, we move them from build.go to meta.go in
order to make the intent clearer.
In moving to the shared HashiCorp release toolkit it was agreed to
remove support for the following architectures ppc64le mips mips64 mipsle mipsle64 s390x
since they are not part of the HashiCorp supported platforms. Nor are
they available as a release binary for any of the Packer plugins.
This change adds an entry to the Packer CHANGELOG to call out the
removal of the said architectures.
As we continue with the path of removing the plugins from Packer core
supporting platforms outside of those managed by our tooling
will be an issue for users as Packer needs the plugins to operate
properly.
When an override block is either not an object, or if one of its
contents are not an object, Packer would crash trying to forcefully
cast the cty.Value to a cty.Collection.
To avoid this behaviour, we add extra checks that return hcl.Diagnostics
when they fail.
When we try to validate a build that contains references to
hcp_packer_image, the data is not fetched, and the value is therefore
unknown.
However, during the decoding phase for the build blocks, we attempt to
fetch the ancestry information for the current build, from the
information previously fetched from HCP.
Since we're validating, there's no way this is set, and attempting to
cast without checking causes Packer to crash on the conversion.
To avoid this, we only attempt this conversion if the value is known.
Closes#11870
* 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.
Wilken Rivera
Lucas Bajolet
Ashish Kurmi
Gary McDonald
Scott Ford
Michele Degges
Lucas Bajolet
Wilken Rivera
Sarah Thompson
Dan Barr
Sylvia Moss
dependabot[bot]
krzys_h
Bryce Kalow
Chris Griggs
Claire Labry
Shohei Maeda