* Update external plugin documentation source
The Linode plugin for Packer is now maintained by the Linode team, under
their respective GitHub org. This changes updates the source address for
the external plugin that should be used for pulling new plugin
documentation.
* Removed packer-plugin-linode for list of vendored plugins
The Linode plugin for Packer is now maintained by the Linode team, under
their respective GitHub org. This changes removes Linode from the vendored plugins
lists.
```
» Go Modules Scanner
⚠︎ found OSV reported vulnerability GHSA-vvpx-j8f3-3w6h in golang.org/x/net@v0.5.0
⚠︎ found OSV reported vulnerability GO-2023-1571 in golang.org/x/net@v0.5.0
```
This change fixes a regression introduced in Packer 1.8.6, where configurations custom builder names
, via the name attribute, would internally interpolate the proper build names, but would display the
name to STDOUT as uninterpolated values. The change updates the creation of a CoreBuild for legacy JSON templates
to use use the interpolated name as the final build type, which gets rendered to the screen.
Test Results Before Fix
```
~> go test ./... -run='TestCoreBuild_buildNameIntepolation' -v
--- FAIL: TestCoreBuild_buildTypeIntepolation (0.01s)
core_test.go:930: build type interpolation failed; expected "test.mybuild-RandomToken", got "test.{{user `build_name`}}"
core_test.go:930: build type interpolation failed; expected "test.build-vardata", got "test.{{user `build_name`}}"
core_test.go:930: build type interpolation failed; expected "test.build-12345", got "test.{{user `build_name`}}"
FAIL
```
Test Results After Fix
```
~> go test ./... -run='TestCoreBuild_buildNameIntepolation' -v
=== RUN TestCoreBuild_buildTypeIntepolation
--- PASS: TestCoreBuild_buildTypeIntepolation (0.01s)
PASS
```
Closes#12281
This change fixes a crash that occurs when trying to add undeclared variables into an empty
variables map. The variables block when defined will always be non-nil but in the case
where variables are declared and initialized from a legacy JSON variables file the map
must be initialized first.
Stable releases for 1.8.x will be made off of the release/1.8.x branch.
Main will represent the next minor version. When ready for a release a new release branch will
be created for the version.
Copywrite is a tool developed internally at Hashicorp in order to
maintain our source code up-to-date in terms of license headers.
Since this will be monitored soon, we are preparing for this by adding
the configuration for files to ignore.
This change will allow for release branches `release/<MAJOR>.<MINOR>.x`
to be built add uploaded to the CRT build tool chain, which can then be
promoted and released publicly if needed.
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
```
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.
