The current behaviour for HCP integration is based on the presence of
the HCP_PACKER_REGISTRY environment variable, where if it is either not
"0" or "off", the HCP integration is enabled.
This commit changes the behaviour to only use this variable to
explicitely disable HCP, and the HCP_PACKER_BUCKET_NAME variable will
condition if the HCP integration is enabled for a build or not in JSON
templates.
For HCL templates, the integration can also be disabled if the
HCP_PACKER_REGISTRY variable is set to "0" or "off", and will be
considered enabled if the HCP_PACKER_BUCKET_NAME is set, or there is a
"hcp_packer_registry" block in a build.
* Separate install instructions; add to external plugins
* Remove duplicate external plugin link; modify overiew page
* Remove unnecessary partials; clean up plugin overview page
* cleaning up plugin explanations
* final language updates
* modify external plugin overview page
* Update website/content/docs/plugins/index.mdx
Co-authored-by: Wilken Rivera <[email protected]>
* Update website/content/docs/plugins/install-plugins.mdx
Co-authored-by: Wilken Rivera <[email protected]>
* Move HCP Support to under developing plugins
* Link HCP Packer support to other dev pages; fix overviews
* clean up more language and links
* Add External Plugins link to docs sidebar under plugin section
* Update website/data/docs-nav-data.json
Co-authored-by: Wilken Rivera <[email protected]>
The latest release of the Oracle plugin for Packer removed
Solaris from its list of supported platforms. Since Packer still
releases binaries for Solaris the Oracle plugin will no longer be
bundled and distributed within the Packer binary. Practitioners relying
on the plugin can continue using the plugin by installing it manually
using either the `packer init` or `packer plugins install` commands.
When a `packer build' is run on a config that does not define anything
to be built, the process would run normally, and only state that no
artifacts were produced after builds were run successfully.
This is misleading as we reach the end of the command without having a
proper warning that nothing was even attempted to be built.
This commit adds a warning when that happens, and leaves immediately
after.
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.
dependabot[bot]
Zach Shilton
Lucas Bajolet
Laura PacilioandWilken Rivera
Lucas Bajolet
Ashish Kurmi
Gary McDonald
Scott Ford
Michele Degges
Wilken Rivera
Sarah Thompson
Dan Barr
Sylvia Moss
krzys_h