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.
* registry: add heartbeat call for running builds
When a build is running, we send periodic heartbeats to HCP Packer's
API.
This will be used on the service side to detect if a build is stalled on
the core side because of a crash or any other malfunction that caused
Packer not to send an update on the status of a build.
* registry: only update status on status update
Prior to this commit, we'd send updates to both the labels and the
cloud-provider whenever an update to the status of a build would be
sent.
This would cause a bug in which once a build reached the post-processing
state, and its cloud-provider was set, the status could not be updated
anymore, as the cloud-provider would be set and further updates are
rejected by the platform.
To avoid this problem, we only transmit the status when doing a status
update, and no other fields along with it.
* internal: publicise CompleteBuild function
The markBuildComplete private function used to be called from a final
status update to DONE, through the UpdateBuildStatus function.
The problem being that the (now) CompleteBuild function not only updates
the status of the build, but also all its metadata.
For consistency, we remove the indirection, and explicitely call
CompleteBuild when we want to finish a build.
* internal: block status updates on DONE builds