When a template describes a build block without a source reference, the
build should be considered invalid as we won't have a CoreBuild produced
as a result of the need to have both.
In current versions of Packer, this will produce an error message
hinting that nothing will happen because of the lack of either build or
source block.
This commit takes the defined block, and points out to it as missing a
source block as being the reason why nothing is happening, making it
clearer what is required for an HCL2 build to be processed.
When a variable is set in a pkrvars file, but isn't defined, an error
message is output, but does not deliver an example of what is expected
by Packer in order to complete a build.
To remedy that, we improve the error message by giving an example of
variable block to include in the build template.
When a template with some builds to run ends its GetBuilds with an
error, and no builds produced, we can exit immediately without printing
more errors.
In order to test the output from a test command, the commandOutput
function exists in the command_test.go file.
Since its behaviour is linked to the test meta that we produce in the
test_utils.go file, we move it there, and rename it to
`GetStdoutAndErrFromTestMeta' to make it clearer what to expect from it.
This commit replaces `os.Setenv` with `t.Setenv` in tests. The
environment variable is automatically restored to its original value
when the test and all its subtests complete.
Reference: https://pkg.go.dev/testing#T.Setenv
Signed-off-by: Eng Zer Jun <[email protected]>
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.
HashiBot
Kevin Wang
Lucas Bajolet
Wilken Rivera
Eng Zer Jun
dependabot[bot]
Zach Shilton
Laura PacilioandWilken Rivera
Lucas Bajolet
Ashish Kurmi
Gary McDonald
Scott Ford
Michele Degges
Wilken Rivera
Sarah Thompson
Dan Barr