In azure templates, the shared_image_gallery was mistakenly considered
an attribute while this is supposed to be a block.
This is due to a heuristic we use for deciding whether a JSON object is
to be translated to an attribute or a block that fell short as the
shared_image_gallery does not contain complex types.
This cannot be fixed trivially for the general case, so we add this
entity to the list of workarounds until we can implement something more
robust.
Some literal strings without format-string directives nor arguments were
littered around the hcl2_upgrade command's code, which is pointed out by
the linters.
Since they serve no purpose, we remove them.
In previous versions of hcl2_upgrade, we referenced a list of
passthrough statements from the original JSON template to be replaced by
their equivalent Go-template in HCL2.
This works but requires us to explicitely accept every possible
templated variable in order to not ever encounter <no value> in our
generated HCL2 templates.
This is suboptimal, hence this commit changes approach by pre-visting
the AST from the original Go Template, escaping every sequence that is
not covered by the list of functions we can migrate. Pipes are also
excluded from this function.
* website: fix broken links on /docs/templates
* fix: redirected install-plugins link
* fix: debugging link
* fix: secrets manager link in docs
* fix: secrets manager link in source
* fix: amazon ami plugin link in docs
* fix: amazon ami plugin link in source
* fix: extending plugins link
* fix: plugins/builders/amazon links
* fix: various builders links
* fix: various amazon builder links
* fix: redirected terminology link
* fix: custom-provisioners link
* fix: docker-push redirected plugin link
* fix: googlecompute plugin links
* fix: hyperv iso plugin links
* website: update link to hcl upgrade guide
Co-authored-by: Wilken Rivera <wilken@hashicorp.com>
Co-authored-by: Wilken Rivera <wilken@hashicorp.com>
The HCP error messages were sometimes a bit terse in terms of the
information it bubbles up to the user.
This made them useful for people who already knew what to look for, but
newcomers would almost certainly be lost because of the lack of
information in those.
To improve on this situation, we reword most of those error messages in
this commit.
JSON templates used only to report the builder's type in HCP builds,
even if the name was specified.
This commit changes this behaviour to include both if they're available,
in a similar fashion as what is done on the HCL2 templates.
Fingerprint initialize was previously occurring during the creation of a
bucket. We want to be able to initialize a bucket and defer the setting
of a fingerprint to a later point.
* Update test to reflect new function signatures for Bucket and Iteration
Loadgin the slug from the environment within the Bucket implied that the
Bucket was successfully created, which may fail outside of a Git
directory when the iteration fingerprint is not set through environment
variables.
To make it possible to print as much information regarding the
environment to the users at once rather than stopping immediately when
this step fails, we move the logic to read the default value from the
environment to the HCP setup code.
When HCP is detected to be enabled, but some configuration is missing,
we returned immediately on the first error.
This commit changes this behaviour by reporting every error at once, so
users will know immediately if something is wrong when they invoke
Packer with HCP support, and one or more environment variables is not
defined as we'd expect them.
The HCP_PACKER_REGISTRY environment variable had its behaviour changed
recently, as prior versions of Packer expected the attribute to be
forcefully set to a value that is neither "off" nor "0" in order to
get HCP integration to work, or that a "hcp_packer_registry" block was
defined in an HCL template. Now, this environment variable defaults to
not explicitely enable, but instead to explicitely disable HCP
integration, and the feature switch fall upon HCP_PACKER_BUCKET_NAME.
As an extra feature, we keep the prior behaviour alive when it is
explicitely defined as a value to enable it. That way we can report
errors if the rest is not defined, rather than silently ignore it.
This function we add to env is the first stone to enable this behaviour.
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 <engzerjun@gmail.com>
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.
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.
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.
* Add tests for plugins install command
* Add tests for plugins remove command
* Add PACKER_GITHUB_API_TOKEN to all test env
* Update dir hashes for non-darwin os
* Update tests with feedback from review
* allowing to set shell env vars from a key/value map.
* tests
This new map will work alongside the `environment_vars` but it allows using a
datasource value seamlessly. At validation, and because `environment_vars` was
an array of strings containing `KEY=value`, using datsources would not work,
because these values are not known yet and would evaluate to `<unknown>`. With
this, the value and the key can be unknown and will validate correctly for
datasources.
* evaluateLocalVariables: modify code for readability and some (not benchmarked) perfs
* Make default input variable type the DynamicPseudoType
This should be the default, and avoids a panic. This type can represent situations where a type is not yet known. Its meaning is undefined in cty.
* do not take Empty types from default value
* Update types.variables.go
Co-authored-by: Wilken Rivera <wilken@hashicorp.com>
The auto installation of external plugins via packer init only work for
HCL templates. Since we have not officially removed all plugins (slated
for 1.8.0) I am reverting this test change. Once 1.7.9 is released we
can begin removing plugins and optimizing the redirect experience for
JSON-only users.
* Add variable interpolation support to hcp_packer_registry block
* Add tests for variable interpolation in hcp_packer_registry block
* Add variable interpolation support to the build block (#11425)
* Add simple test to build command
* add test for crash
* fix
* show more precise error message when parse of a provisioner fails
* Revert "fix"
This reverts commit fc88e89fbb.
* add better severity
