In trying the example, I found that you have to type "*.second-example" for the expected results. I took the command line on line #78 literal and it didn't work as typed. When I used my proposed change... it worked for me.
Alternatively, "*.second*" works but that could grab builders that were not intended.
This change introduces the new actions-set-product-version, a tiny, but mighty, GitHub action that acts as a bridge between the product repo and our new CRT feature: automated version bumping.
tl;dr automated version bumping has a new command (bob update version) in the bob CLI that automatically bumps the version to a new patch. This automation has been introduced to crt-workflows-common as a new workflow (with the new bob command) and handles version bumping at the end of the release pipeline (after being released to production); for example, 1.0.0→1.0.1 and 1.0.0-dev→1.0.0. Bumping the minor version (ie 1.0.x→1.1.0) is only supported manually via bob update version -bump minor, but not supported in CRT (this work is upcoming). This is made possible by adding the new event “bump-version” in the ci.hcl file in this PR.
What this small action does:
Allows for the static version string from the version/VERSION file to be read by the new CRT workflow and automagically be bumped to the next version (whether it be a minor, or patch, or major version bump).
Outputs an error if there’s no VERSION file in the version dir
Outputs an error if there’s no version string in the VERSION file
Is able to parse product_version if it is 1.3.0-alpha1 as 1.3.0 (example: when product_version = 1.3.0-alpha1, base_version = 1.3.0)
Is able to parse prerelease product versions such as alpha1 (example prerelease_product_version = alpha1) in the statement above.
* hcl2template: use && for chaining conditions
For deciding if we need to run an error provisioner block, we checked
using a nested if that we didn't need to avoid running it.
This is unnecessary, and adds a superfluous level of inbrication to the
code, so we chain both conditions with &&.
* hcl2: don't warn on excluded post-processor
When a post-processor is excluded through the -except command-line
argument for packer build, we used to print a warning on HCL2 templates
if this except statement did not match a build.
However, since we can use the except option to avoid running
post-processors, we should account for this as well when printing out a
warning that there were no matches.
This commit adds this counter to the except checks for the
post-processors as well.
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.
Related to the previous behaviour problem, this changes how the status
of a build is set on HCP Packer, as a cancelled build is different from
a failed one, we can set it to the appropriate state on cancellation.
When a build is cancelled by a user, the current implementation of
CoreBuild.Run does not return an error signifying that there was a
problem with the build.
This in turn causes the HCP code to attempt to update the status of the
build to DONE, but fails because there are no artifacts to push.
This commit changes this behaviour by returning the error provoked by
the cancellation to the caller, so it can be taken into account when
setting the status of the build.
The latest version of Go-Getter contains a SMBClient timeout option,
along with an updated AWS SDK to improve S3 support.
```
go get github.com/hashicorp/go-getter/v2
go get github.com/hashicorp/go-getter/s3/v2
go get github.com/hashicorp/go-getter/gcs/v2
go mod tidy
```
While looking into #11932 I found that Packer will throw an error when
an unknown source is referenced from within the sources attribute for
a build block. The hcl.Diagnostics error includes a Subject, which
should highlight where in the HCL2 configuration file the unknown source resides.
But when creating the BuildBlock no HCL2Ref data is copied over, thus the
Subject is displayed with with zero value for an hcl.Range type.
This change updates the build creation logic to copy the HCL2Ref data
from the build block at decode time so that it can be properly
referenced downstream.
Closes#11932
Failure due to change in output
```
--- FAIL: TestValidateCommand_ShowLineNumForMissing (0.00s)
--- FAIL: TestValidateCommand_ShowLineNumForMissing/test-fixtures/validate-invalid/missing_build_block.pkr.hcl (0.00s)
validate_test.go:377: Unexpected output: (
"""
Error: Unknown source file.cho
- on line 0:
+ on test-fixtures/validate-invalid/missing_build_block.pkr.hcl line 6:
(source code not available)
... // 4 identical lines
"""
)
validate_test.go:379:
FAIL
FAIL github.com/hashicorp/packer/command 1.002s
```
Currently go-test and go-validate only run for users who have push
access to the Packer repo. We want to ensure tests and validation run
for all opened pull requests including public forks.
As with the go version to 1.18.9, this fix concerns mitigations to the
GO-2022-1144 vulnerability.
Since we depend on golang.org/net too, we need to update it to a version
that is not vulnerable anymore, and this is starting at version 0.4.0
This PR add [`tart` builder](https://github.com/cirruslabs/packer-plugin-tart) to the list of all the builders.
Tart is a open-source toolset for building, running and managing Linux and macOS virtual machines on Apple Silicon. Part of the toolset is this packer plugin.
The go 1.18.9 version fixes a vulnerability GO-2022-1144, which concerns
the net/http and golang.org/x/net packages.
These are used in the codebase, and therefore automated tools report the
generated binaries as vulnerable to this.
Note that while Packer is indeed vulnerable to this, this is a DoS
attack. This is therefore unlikely to impact Packer severely, especially
as it requires a deliberate attempt to provoke an OOM/excessive GC
cycles.
Nonetheless, since this vulnerability is fixed with go 1.18.9, we bump
the version used to build/test the tools to this version.
```
Usage: packer validate [options] TEMPLATE
Checks the template is valid by parsing the template and also
checking the configuration with the various builders, provisioners, etc.
If it is not valid, the errors will be shown and the command will exit
with a non-zero exit status. If it is valid, it will exit with a zero
exit status.
Options:
-syntax-only Only check syntax. Do not verify config of the template.
-except=foo,bar,baz Validate all builds other than these.
-only=foo,bar,baz Validate only these builds.
-machine-readable Produce machine-readable output.
-var 'key=value' Variable for templates, can be used multiple times.
-var-file=path JSON or HCL2 file containing user variables, can be used multiple times.
-no-warn-undeclared-var Disable warnings for user variable files containing undeclared variables.
-evaluate-datasources Evaluate data sources during validation (HCL2 only, may incur costs); Defaults to false.
```
As a follow-up to tracking the template type for an iteration, we
actively check that it remains consistent between two invocations of
packer, and reject the update if it is not the case.
In order to ensure users keep the same templates between two packer
invocations for a single iteration, we start tracking the type of
template used when building images.
Currently the HCL2 upgrade command generates a valid variable block for all variables
within the JSON variables property. However JSON templates in Packer support variable
interpolation for input variables defined within a variable definition file without
it being declared within the variables property. When upgrading a JSON template to HCL2
the user variable reference gets converted to var.<var_name>. The upgraded template ultimately
fails on validation or build execution with undefined variable errors, with this change the upgrade
command will now create a variable block for all input variables referenced within the build template
to ensure all required variables been defined.
The `packer-image-iteration' datasource is an undocumented, and
unexported datasource, so it cannot be used by clients.
Since this is dead weight, we can remove it safely from the codebase.
In JSON templates, we register the builds to process on HCP at the
initialisation of the Registry.
However, during the HCP breakout, this code was duplicated with a slight
difference for the JSON templates, and the build names were registered
once during initialisation, with the expected full name, and once at the
start of PopulateIteration, with the truncated name.
This caused a bug when processing a template that contains a builder
with both a name and a type, as both would be registered, but only one
would complete, leading to the iteration being unable to complete.
When the options for bypassing/enabling assigned and undeclared
variables were added to Packer, the website documentation for those
commands and options was not updated.
This commit adds some documentation for those options.
When packer validate is invoked, it does not try to evaluate the
datasources before attempting to decide if the template is valid.
In many cases, this works, but sometimes it will fail as the value is
unknown by the validation code.
Since the validation code for all the elements of a Packer template is
left to be implemented by plugins, we cannot rely on checking for
unknown values everywhere, especially since the unknown references are
replaced automatically by a value of the right type for the
configuration expected.
So, in order for such configurations to be validable, we add an extra
option to packer validate, that will let users evaluate the datasources
from a template.
* Update validation options for undeclared variables
In an effort to help users move from JSON to HCL2 templates the support for
variable definitions files are being updated to ignore undeclared
variable warnings on build execution. For legacy JSON templates builds no
warnings are displayed when var-files contain undeclared variables.
Since preferred mode HCL2 templates is to be explicit with variable
declarations - they must be declared to be used - validation for
undeclared variables still warns when running `packer validate`. A new
flag has been added to the validate command that can be used to disable
undeclared variable warnings.
* Update validation test for unused variables
Example Run
```
~> go run . validate -no-warn-undeclared-var -var-file
command/test-fixtures/validate/var-file-tests/undeclared.pkrvars.hcl
command/test-fixtures/validate/var-file-tests/basic.pkr.hcl
The configuration is valid.
~> go run . validate -var-file
command/test-fixtures/validate/var-file-tests/undeclared.pkrvars.hcl
command/test-fixtures/validate/var-file-tests/basic.pkr.hcl
Warning: Undefined variable
The variable "unused" was set but was not declared as an input variable.
To declare variable "unused" place this block in one of your .pkr.hcl
files,
such as variables.pkr.hcl
variable "unused" {
type = string
default = null
}
The configuration is valid.
~> go run . build -var-file
command/test-fixtures/validate/var-file-tests/undeclared.pkrvars.hcl
command/test-fixtures/validate/var-file-tests/basic.pkr.hcl
file.chocolate: output will be in this color.
Build 'file.chocolate' finished after 744 microseconds.
==> Wait completed after 798 microseconds
==> Builds finished. The artifacts of successful builds are:
--> file.chocolate: Stored file: chocolate.txt
```
* Rename Strict field to WarnOnUndeclaredVar
The field name Strict is a bit vague since it is only used for
checking against undeclared variables within a var-file definition.
To mitigate against potential overloading of this field it is
being renamed to be more explicit on its usage.
* command/build: Add warn-on-undeclared-var flag
Now that the default behaviour is to not display warnings for undeclared variables
an optional flag has been added to toggle the old behaviour.
```
~> go run . build -warn-on-undeclared-var -var-file command/test-fixtures/validate/var-file-tests/undeclared.pkrvars.hcl command/test-fixtures/validate/var-file-tests/basic.pkr.hcl
Warning: Undefined variable
The variable "unused" was set but was not declared as an input variable.
To declare variable "unused" place this block in one of your .pkr.hcl files,
such as variables.pkr.hcl
variable "unused" {
type = string
default = null
}
file.chocolate: output will be in this color.
Build 'file.chocolate' finished after 762 microseconds.
==> Wait completed after 799 microseconds
==> Builds finished. The artifacts of successful builds are:
--> file.chocolate: Stored file: chocolate.txt
```
The ancestry inferral code relied on HCP datasource outputs for deciding
what would be the ancestry for an image built with HCP.
This brings a dependency into the hcp package, which is not really
necessary as we only need a few information from those entities, hence
this commit removes the full dependency on the structures, in favour of
more focused data structures where we only cherry pick what is necessary
for this code.
This commit reorganises the code for both the registry/API and the
Orchestrator/Registry.
The main difference with the previous version is how stuff is exposed.
Now we only expose a Registry interface to the outside (previously named
Orchestrator), which has several implementations: null is the default,
and is returned if HCP is not enabled.
The other implementations being HCL/JSON, both private to the hcp
sub-package.
The api (previously `registry') is the set of functionality that
abstracts and calls the HCP API.
It was meant to be merged with the `hcp' package, but because of a
dependency loop with the datasources, both are separated for now.
As part of the work to displace everything related to HCP from scattered
places around the Packer code, we move it all to an hcp package.
This in turn reduces the amount of code that the commands have to
integrate, and leaves the HCP details to its own enclave.
To be able to track HCP builds during a Packer build, we need to
propagate the name used for registering the build to HCP.
This works out-of-the-box for JSON templates, as the build's name is
always the builder's, so there's no confusion on that.
For HCP templates however, there's a possibility for a template to
define a name for the build, which is returned by a CoreBuild's Name()
function, in addition to the source's Type/Name.
The builds are registered to HCP with the source.String() function
however, which does not contain the build's name. This prevents any
build containing a name to work, as their name/source.String does not
match.
The name we registered the build with is stored in a CoreBuild as the
Type attribute, but cannot be safely accessed, as builds are types
within the command as packersdk.Build, which only exposes Name() for
this purpose.
In order to circumvent this problem, and as a way to present a prototype
of solution that will likely have to be discussed before we merge it,
this commit hotfixes the issue.
craigpero
dependabot[bot]
claire labry
Gary McDonald
Wilken Rivera
Mariano Asselborn
Ashlee Boyer
Lucas Bajolet
Lucas Bajolet
Wilken Rivera
Fedor Korotkov
Christophe Jauffret
HashiBot
Ashlee M Boyer