Skip to content

Release Packer version 1.16.1 - #13708

Merged
sanyaraj2424 merged 10 commits into
release/1.16.xfrom
backport/release/1.16.1
Sep 15, 2026
Merged

sanyaraj2424 merged 10 commits into
release/1.16.xfrom
backport/release/1.16.1

Conversation

@sanyaraj2424

Copy link
Copy Markdown
Collaborator

This pull request primarily updates dependencies and copyright years, and introduces the changelog for the 1.16.1 release. The most significant changes include updating the Go version, bumping various GitHub Actions and third-party dependencies, and adding new features and fixes as documented in the changelog.

Release and Documentation Updates:

  • Added the changelog for version 1.16.1 in CHANGELOG.md, detailing new features, improvements, bug fixes, security updates, dependency bumps, and internal changes.
  • Updated the README contribution link to point to the main branch instead of master.

Dependency and Tooling Updates:

  • Updated the Go version in .go-version from 1.26.3 to 1.26.8.
  • Bumped versions for several GitHub Actions across workflow files, including actions/checkout, actions/setup-go, aws-actions/configure-aws-credentials, slackapi/slack-github-action, and Atlassian Jira actions, ensuring the latest security and feature updates.

eb4x and others added 10 commits August 10, 2026 13:32
…iables (#13686)

HCL2 builds do not send the packer_user_variables config key to the
builder, provisioner and post-processor plugins. Legacy JSON builds
send this key (through CoreBuild.packerConfig()). Without the key, the
plugin SDK keeps interpolate.Context.UserVariables nil. Then the
template function {{ user "name" }} fails with 'error calling user:
test'. This failure occurs in each string that a plugin interpolates at
run time, for example the contents of the vagrant post-processor's
vagrantfile_template.

Add the function PackerConfig.userVariableValues(). This function
converts the input variable values to strings, equivalent to the legacy
user variables. The core sends the map at each plugin handoff point:
builder, provisioner, post-processor, and enforced provisioner.

The map does not contain the sensitive variables. A sensitive value
goes to a plugin only if the template refers to it explicitly. The map
does not contain values that are not primitive (lists, maps, objects).
Legacy user variables were always strings.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* go.mod version upgrade

* actions upgrade
Packer can only install plugins from github.com, with
releases.hashicorp.com consulted first for HashiCorp-published plugins.
This has been a long-standing gap for air-gapped and policy-restricted
environments (#11164): the source address parser already accepts any
hostname, but both existing getters reject non-github.com sources at
install time.

Add a remote plugin getter that installs plugins from the host named in
a required_plugins source address. The host serves the directory
structure of releases.hashicorp.com under the source's path: an
index.json listing versions, and per version a SHA256SUMS file, the
zips it lists, and - when the zip names carry no plugin protocol
version - the version's manifest.json. A plugin published on
releases.hashicorp.com is therefore mirrored as a verbatim copy of its
tree, with every checksum file and signature upstream-authored. A
plugin published as GitHub release assets is mirrored by copying each
release's assets into a version directory, renaming their SHA256SUMS
file to the unprefixed convention with content unchanged, and writing
an index.json listing the versions. Both kinds of content can be
served side by side by one host.

Getter selection happens per source address: github.com sources keep
the release and github getters unchanged, while any other host is
served by the remote getter over HTTPS. Sources with three or more
components are supported, up to the existing 16-component limit, so
nested artifact-repository paths and hosts that embed the upstream
origin in their path all resolve.

Version discovery, constraint solving, checksum verification, and the
binary naming rules match the existing getters. The installed filename
is rebuilt from validated checksum-file fields and never taken from the
server's response, checksum entries matching neither known naming shape
are rejected rather than guessed at, and nothing the remote metadata
supplies is used to fetch from another origin or path. index.json
parsing is covered by fixtures captured from the live releases API, so
a format change there fails tests rather than user installs.

Closes #11164
fix: update link to CONTRIBUTING.md for consistency with main branch
Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.83.1 to 1.83.2.
- [Release notes](https://github.com/grpc/grpc-go/releases)
- [Commits](grpc/grpc-go@v1.83.1...v1.83.2)

---
updated-dependencies:
- dependency-name: google.golang.org/grpc
  dependency-version: 1.83.2
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* [COMPLIANCE] Add/Update Copyright Headers

* make generate update

* make generate

---------

Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: sanya <sanya24@ibm.com>
Co-authored-by: Sanya <rajsanya2424@gmail.com>
@sanyaraj2424
sanyaraj2424 requested a review from a team as a code owner September 15, 2026 15:44
@hashicorp-cla-app

hashicorp-cla-app Bot commented Sep 15, 2026 •

Copy link
Copy Markdown

CLA assistant check

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes


3 out of 4 committers have signed the CLA.

  • sanyaraj2424
  • benemon
  • eb4x
  • elomito

Have you signed the CLA already but the status is still pending? Recheck it.

@hashicorp-cla-app

hashicorp-cla-app Bot commented Sep 15, 2026 •

Copy link
Copy Markdown

CLA assistant check

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes


3 out of 4 committers have signed the CLA.

  • benemon
  • eb4x
  • sanyaraj2424
  • elomito

Have you signed the CLA already but the status is still pending? Recheck it.

@sanyaraj2424
sanyaraj2424 merged commit 9408d6d into release/1.16.x Sep 15, 2026
54 of 55 checks passed
@github-actions

Copy link
Copy Markdown

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Oct 16, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants