```
» Go Modules Scanner
⚠︎ found OSV reported vulnerability GHSA-vvpx-j8f3-3w6h in golang.org/x/[email protected]
⚠︎ found OSV reported vulnerability GO-2023-1571 in golang.org/x/[email protected]
```
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
```
In packer v1.8.5, the bucket's description was not properly set in the
bucket object we use for HCP, therefore all the buckets created by
Packer did not have their description updated.
Before the change
```
--- FAIL: TestReadFromHCLBuildBlock (0.00s)
--- FAIL: TestReadFromHCLBuildBlock/configure_bucket_using_only_hcp_packer_registry_block (0.00s)
types.bucket_test.go:380: expected the build to to have contents of hcp_packer_registry block but it does not: ®istry.Bucket{
Slug: "hcp_packer_registry-block-test",
- Description: "",
+ Description: "description from hcp_packer_registry block",
Destination: "",
BucketLabels: {"org": "test"},
... // 5 identical fields
}
FAIL
FAIL github.com/hashicorp/packer/internal/hcp/registry 1.072s
FAIL
```
After Change
```
~> go test ./...
? github.com/hashicorp/packer/internal/hcp/api [no test files]
ok github.com/hashicorp/packer/internal/hcp/env (cached)
ok github.com/hashicorp/packer/internal/hcp/registry 1.130s
```
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.
hc-github-team-packer
Wilken Rivera
dependabot[bot]
hc-github-team-es-release-engineering
Wilken Rivera
Claire
craigpero
Gary McDonald
Ashlee Boyer
Lucas Bajolet
Lucas Bajolet
lonegunmanb