Fingerprints are how we link a packer build to an iteration on HCP.
These are computed automatically from the Git SHA in the current state,
and are unique to the bucket/iteration.
The main problem with this approach is that while sound in theory, it
quickly falls apart when users want to run the same build configuration
twice, but expect a new image to be created.
With the current model, this fails, as the iteration with the current
SHA already exists.
While this is solvable through environment variables, or by committing a
change to the repository, we think this is not clear enough, and causes
an extra step to what should otherwise be a simple process.
Therefore, to lower the barrier of entry into HCP, we change this
behaviour with this commit.
Now, fingerprints are randomly generated ULIDs instead of a git SHA, and
a new one is always generated, unless one is already specified in the
environment.
This makes continuation of an existing iteration a conscious choice
rather than something automatic, and virtually eliminates conflicts such
as the ones described above.
The iteration structure that we use for linking a packer build to an
iteration on HCP defines a `Labels' attribute, which is never set nor
read from at any point.
Since it is unused, we remove it in this commit.
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.
Ashlee M Boyer
Kendall Strautman
dependabot[bot]
Lucas Bajolet
lonegunmanb
Wilken Rivera
craigpero
claire labry
Gary McDonald
Mariano Asselborn
Ashlee Boyer
Lucas Bajolet
Fedor Korotkov
Christophe Jauffret
HashiBot