v1.11.0
1.11.0 (2024-05-31)
NOTES:
-
A LICENSE.txt file has been added to the Packer release artifacts.
GH-12931
GH-12940 -
Breaking Change: Support for loading single-component plugins has been removed from Packer. GH-12785
-
Breaking Change: Support for loading plugin binaries following
the naming convention of packer-plugin-name has been dropped. Packer will now only load
plugins stored under the Packer plugin directory using the expected namespaced
directory and CHECKSUM files. This change drops support for loading plugin
binaries in Packer's executable directory or a template's current working
directory. GH-12828
/Users/dev/.packer.d/plugins
└── github.com
└── hashicorp
└── happycloud
├── packer-plugin-happycloud_v0.0.1_x5.0_darwin_arm64
└── packer-plugin-happycloud_v0.0.1_x5.0_darwin_arm64_SHA256SUM
FEATURES:
- core: Add
-ignore-prerelease-plugins
flag to disable the use of development
plugin binaries for thebuild
andvalidate
commands development plugin
binaries. GH-12828
GH-12882 - Packer users can now track Packer version and plugin versions used for each
build artifact in HCP Packer.
GH-12866 - hcl2: add textencodebase64 and textdecodebase64 funcs
For feature parity with Terraform, and since having access to strings
encoded in something that is not UTF-8 is required in some cases, we add
both the textencodebase64 and textdecodebase64 functions to HCL2 templates.
Please note these functions return base64 encoded byte slices because of how
cty/hcl defines strings (NFC normalised, UTF-8 encoded).
GH-12997
SECURITY:
- Bump github.com/go-jose/go-jose/v3 to address GHSA-c5q2-7r4c-mv6g.
GH-12880 - Bump golang.org/x/net to v0.24.0 to address GO-2024-2687.
GH-12924
IMPROVEMENTS:
- core: Bump github.com/hashicorp/hcp-sdk-go from 0.90.0 to 0.96.0.
GH-12935
GH-12942
GH-12960
GH-12979 - core: Bump github.com/hashicorp/packer-plugin-sdk from 0.5.2 to 0.5.3
GH-12932 - core: Bump go-getter/v2 from 2.2.1 to v2.2.2
GH-12988 - datasource/http: don't error on 2xx code
Previous versions of Packer only supported 200 as a success case for the http
datasource. This change makes any status code from 200 to 299 successful.
GH-12989 - core: Move to predictable plugin loading schema - Packer will now only load
plugins stored under the Packer plugin directory using the expected namespaced
directory and CHECKSUM files.
GH-12828 - core: Remove support loading single-component plugins.
GH-12785 - core: Rename internal
packer plugin
command topacker execute
to avoid user confusion with
the plugins subcommand.
GH-12865 - core: Packer now considers development binaries when evaluating plugin
version constraints. This work allows users to use binaries with versions
reported as "x.y.z-dev" to be used with the Packerrequired_plugins
block. GH-12828 - core: Packer now supports local paths to plugins for the
packer plugins remove
command. This addition makes it possible to pipe commands like
packer plugins installed
with it for speedy cleanup of installed plugins.
GH-12886 - core: Relax Packer source address URIs within the
required_plugins
block to
support the installation of local plugin binary using a custom or internal
source address (e.g. mycompany.com/plugins/happyorg/happycloud). Remote
installation usingpacker init
orpacker plugins install
does not
support non-GitHub source URIs. Users using alternative hosts must
install plugins manually usingpacker plugins install --path
.
GH-12911, [GH-12962] (#12962) - core: Remote plugins installed containing an internal version number that
differs from the version number within the binary name can lead to
confusion when tracking Packer plugin version information. To help track
such discrepancies in the plugin version,packer init
andpacker plugin install
have been updated to reject installation of such plugins.
1.0.0-dev). Users are encouraged to notify plugin maintainers of any
version mismatches.
GH-12915, GH-12953, GH-12972 - core: don't load plugins with metadata in name
To avoid confusion with multiple plugins that report the same effective version,
plugins installed need to have no metadata in their name.
When installed through Packer commands, the metadata is scrubbed from the name of the
installed plugin binary, but manually it may still be possible, so we enforce
that scrubbing at load-time as well.
GH-12980 - core: Error when multiple paths are specified for PACKER_PLUGIN_PATH
Since Packer 1.11 removed the capability for PACKER_PLUGIN_PATH to specify
multiple directories separated by:
or;
(depending on the platform), we
are explicitly erroring when this is discovered, with suggestions as to how
to fix the problem.
GH-12967 - core: Version metadata support for plugins. Plugins may now formally have metadata
in their versions, Packer supports it, and applies the semver recommendations on
them, i.e. they are ignored for comparison/sorting purposes, but allowed for
adding extra information about a plugin.
GH-12888
Given the specified version constraint only versions greater than or equal to 1.1.0 will be considered.
amazon = {
source = "github.com/hashicorp/amazon"
version = ">= 1.1.0"
}
If a development binary is installed, Packer will use it if:
- It is the highest compatible version installed.
- There is no final plugin version with the same version number installed alongside it.
/Users/dev/.packer.d/plugins
└─ github.com
└─ hashicorp
└── amazon
├── packer-plugin-amazon_v1.1.0_x5.0_darwin_arm64
├── packer-plugin-amazon_v1.1.0_x5.0_darwin_arm64_SHA256SUM
├── packer-plugin-amazon_v1.1.1-dev_x5.0_darwin_arm64
└── packer-plugin-amazon_v1.1.1-dev_x5.0_darwin_arm64_SHA256SUM
Version 1.1.1-dev of the Amazon plugin will match the specified version constraint and be used for executing the Packer build.
If, however, a 1.1.1 release version of the plugin is available, it will have precedence over the development binary.
/Users/dev/.packer.d/plugins
└─ github.com
└─ hashicorp
└── amazon
├── packer-plugin-amazon_v1.1.1-dev_x5.0_darwin_arm64
├── packer-plugin-amazon_v1.1.1-dev_x5.0_darwin_arm64_SHA256SUM
├── packer-plugin-amazon_v1.1.1_x5.0_darwin_arm64
└── packer-plugin-amazon_v1.1.1_x5.0_darwin_arm64_SHA256SUM
BUG FIXES:
- core: fix plugin version ordering to not be lexicographic. This fixes an issue
with how plugins are discovered by Packer, and ensures proper version ordering.
This means that with this change, versions that are semantically greater,
but lexicographically inferior will be loaded.
Ex: 1.0.9 vs. 1.0.10;1.0.9 > 1.0.10
lexicographically, but semantically
1.0.10 > 1.0.9
- core/hcp: fix potential race condition when storing plugin details to the HCP
Packer metadata storage map.
GH-12936 - core: fix plugin listing on Windows
This fix addresses bugs present in the alpha releases of 1.11, where
the discovery of Windows binaries were not matching against the
filename extension (.exe).
GH-12981