Skip to content
This repository was archived by the owner on Jul 23, 2025. It is now read-only.

Commit 298be01

Browse files
docs: add upgrade/release notes for 1.12.0
1 parent f1442be commit 298be01

3 files changed

Lines changed: 126 additions & 0 deletions

File tree

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
---
2+
page_title: Packer v1.12 release notes
3+
description: Learn about the changes in Packer v 1.12
4+
---
5+
6+
# Packer v1.12 release notes
7+
8+
This page describes changes to Packer in v1.12. Refer to the [Packer repository](https://github.com/hashicorp/packer/releases) for information about all releases.
9+
10+
## New features
11+
12+
This release includes the following updates.
13+
14+
### HCP Packer SBOM Support
15+
16+
In Packer 1.12, you can upload software bill of materials (SBOMs) to HCP Packer and associate it with an artifact version.
17+
SBOMs are a standardized way to export information about a system.
18+
In Packer's case, the generally useful information that you may find in a SBOM for an artifact is the list of installed packages, along with extra information on the system built: OS, version, kernel, architecture, etc.
19+
20+
While we support uploading SBOMs to HCP Packer as part of a build, we do not offer a special-purpose provisioner or tooling to produce them.
21+
Instead we encourage you to use a third-party scanner to produce the SBOM on the VM you are provisioning, and then you can use the [`hcp-sbom` provisioner](https://developer.hashicorp.com/packer/docs/provisioners/hcp-sbom) to upload it when your Packer build completes.
22+
23+
### Data source and Locals evaluation order changes
24+
25+
Older versions of Packer used a phase-based approach, where it evaluated data sources first, then local variables.
26+
This made it impossible for a data source to reference a local variable.
27+
28+
Packer 1.12 introduces a Directed Acyclic Graph (DAG) approach to evaluating data sources and locals.
29+
This loosens the dependency order between those components, and now you can reference them from both contexts.
30+
31+
This change is a step in the direction of a complete pivot to using a DAG for evaluating everything in a Packer build, along with the other improvements this can yield in future releases.
32+
33+
### Serialisation format upgrades for Packer-Plugin communication
34+
35+
More than one year ago, a dependency of ours (`go-cty`) dropped support for `gob` encoding.
36+
This made it impossible for plugin developers to upgrade to more recent versions of the HCL2 libraries, because otherwise their plugin became incapable to commuinicate with Packer.
37+
We temporarily addressed this issue by forking the `go-cty` repository, and introduced replacement directives to every Packer plugin.
38+
While this fix was functional, it was not desirable as a long-term solution, and instead we were looking for a more permanent fix.
39+
40+
Now, when Packer communicates with plugins, it swaps to using a protobuf/msgpack hybrid approach instead of relying on `gob`.
41+
We are introducing this change now in a non-breaking way: all the currently supported plugins are expected to continue working with Packer for the time being, and changing to using this new serialization approach will be transparent to you.
42+
43+
### New HCL2 functions
44+
45+
As part of Packer 1.12, we have introduced more functions that can be used in HCL2 templates, and one (`aws_secretsmanager_raw`) that can be used both in legacy JSON and HCL2 templates.
46+
47+
* `anytrue`: check that a collection contains at least one `true` value.
48+
* `alltrue`: check that a collection contains only `true` values.
49+
* `aws_secretsmanager_raw`: get a raw secret from AWS Secrets Manager. Unlike `aws_secretsmanager`, this works with all types.
50+
* `base64gzip`: gzip compress a binary blob and expose it as a base64-encoded `string` to be used elsewhere in a template.
51+
* `strcontains`: checks that a string contains another.
52+
53+
### `HTTP` data source support methods other than `GET`
54+
55+
The HTTP data source, embedded with Packer, lets you retrieve data over HTTP from a remote server.
56+
Previous versions of Packer only supported `GET` to do so. Packer 1.12 loosens this by allowing for: `HEAD`, `GET`, `POST`, `PUT`, `DELETE`, `OPTIONS` and `PATCH`.
57+
58+
## Bug fixes
59+
60+
### Include LC_UUID in macOS binaries
61+
62+
Users of macOS started having permission-related problems when using Packer, after upgrading their OS versions.
63+
This problem was caused by an update to macOS's network-usage policies, where binaries that want to use the local loop interface to communicate over the network must now include a valid UUID.
64+
Starting with Packer 1.12, all macOS binaries include a valid LC_UUID, fixing this.
65+
66+
### Less duplication of error messages in HCL2 templates
67+
68+
If a template has an error in its top-level HCL2 template, Packer produces a parsing error.
69+
This is expected behavior when you write a Packer template: the tool helps you by pointing out grammar violations so you can remediate them.
70+
However, for a subset of HCL-related errors, older versions of Packer displayed the same message up to five times.
71+
Thanks to a community contribution, starting with Packer 1.12 we now no longer experience this.
Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
---
2+
page_title: Upgrade to v1.12
3+
description: Learn how to upgrade your Packer installation to v1.12
4+
---
5+
6+
# Upgrade to v1.12
7+
8+
The topic describes upgrade considerations for Packer v1.12. Refer to the [v1.12 release notes](/packer/docs/release-notes/v1_12) for details about changes in v1.12.
9+
10+
## Overview
11+
12+
You can use the upgrade command for the package manager you installed Packer with or download and replace the existing binary to upgrade Packer. Refer to [Install Packer](https://developer.hashicorp.com/packer/install) for instructions.
13+
14+
## Upgrade from 1.11
15+
16+
Packer 1.12's notable changes can be summarised by the following points:
17+
18+
1. Protocol changes for Packer/plugin communication
19+
2. Introduction of a Directed Acyclic Graph (DAG) for Data Sources and Locals
20+
21+
**Note**: These are not breaking changes, and your templates should continue working as-is.
22+
23+
## Protocol changes
24+
25+
When initialising, Packer is now able to pick between two different protocols for communication with plugins: gob (legacy), and protobuf/msgpack.
26+
27+
The protobuf/msgpack protocol will become the standard approach after this release, but in order to avoid breaking retro-compatibility, Packer only chooses this protocol if the following conditions are true:
28+
29+
1. All the plugin candidates for a build support the new protocol
30+
2. Packer supports the protocol
31+
32+
This is an internal Packer change and should be completely transparent to you.
33+
However, if you start seeing errors with Packer/plugin communication like serialization errors, please [report it to us](https://github.com/hashicorp/packer/issues) so we can fix it in a later version.
34+
You can set the `PACKER_FORCE_GOB` environment variable to force Packer and plugins to use the legacy serialization format for communication.
35+
36+
Example: `export PACKER_FORCE_GOB=1` will force using gob for serialization.
37+
38+
## Data Source and Locals DAG support
39+
40+
In order to allow more flexibility in how you define data sources and locals, we introduced a graph-based approach to scheduling the evaluation of those components.
41+
With this change, you can use a local variable in a data source, and vice-versa. You are not bound to a strict evaluation order.
42+
43+
If your templates worked with older versions of Packer, this change should be transparent to you.
44+
However, if you are experiencing errors with your data sources or locals, typically errors due to unkown values, or other dependency problems, please [report it to us](https://github.com/hashicorp/packer/issues) so we can fix it in a later version.
45+
You can use the `--use-sequential-evaluation` command-line option can be used to revert back to the evaluation scheduler that Packer used prior to v1.12.0.
46+
47+
Example: `packer build --use-sequential-evaluation <TEMPLATE>` will force Packer to use the sequential evaluation methods.

website/data/docs-nav-data.json

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -876,6 +876,10 @@
876876
{
877877
"title": "v1.11",
878878
"path": "release-notes/v1_11"
879+
},
880+
{
881+
"title": "v1.12",
882+
"path": "release-notes/v1_12"
879883
}
880884
]
881885
},
@@ -885,6 +889,10 @@
885889
{
886890
"title": "Upgrade to v1.11",
887891
"path": "upgrade/v1_11"
892+
},
893+
{
894+
"title": "Upgrade to v1.12",
895+
"path": "upgrade/v1_12"
888896
}
889897
]
890898
},

0 commit comments

Comments
 (0)