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.
Assigning the sync to jira label multiple times to an issues causes
multiple Jira tickets to be created. This new change adds a ticket
search to find any previously created ticket in Jira for the labeled
issue. If a ticket already exist the action will skip the create step.
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
Wilken Rivera
Lucas Bajolet
Wilken Rivera
dependabot[bot]
Mariano Asselborn
CalebAlbers
Mariano Asselborn
Bryce Kalow
HashiBot
Kevin Wang
Eng Zer Jun
Zach Shilton
Laura PacilioandWilken Rivera
Lucas Bajolet
Ashish Kurmi
Gary McDonald
Scott Ford
Michele Degges