On HCP, multiproject support was GA'd recently, but Packer does not
support the feature yet.
To avoid clients being surprised if they encounter an error with this
feature enabled, we add an advisory related to this feature not being
supported for now, but planned for later.
Fingerprints are how we link a packer build to an iteration on HCP.
These are computed automatically from the Git SHA in the current state,
and are unique to the bucket/iteration.
The main problem with this approach is that while sound in theory, it
quickly falls apart when users want to run the same build configuration
twice, but expect a new image to be created.
With the current model, this fails, as the iteration with the current
SHA already exists.
While this is solvable through environment variables, or by committing a
change to the repository, we think this is not clear enough, and causes
an extra step to what should otherwise be a simple process.
Therefore, to lower the barrier of entry into HCP, we change this
behaviour with this commit.
Now, fingerprints are randomly generated ULIDs instead of a git SHA, and
a new one is always generated, unless one is already specified in the
environment.
This makes continuation of an existing iteration a conscious choice
rather than something automatic, and virtually eliminates conflicts such
as the ones described above.
This commit irons out one of the pain points of the HCP rework by
introducing a HCPPublisher interface, implemented both by the JSON Core,
and the HCL2 PackerConfig, which keeps a map of the build names used by
Packer to the build names pushed on HCP.
This in turn lets us go back to the old implementation of the GetBuilds
function, which returns a list of (filtered) builds, and eventually an
error if something went wrong while processing.
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.
