The Makefile would check for executable files inside the Packer
repository, and produce errors if one was detected and not explicitely
whitelisted through the `EXECUTABLE_FILES' Makefile variable.
This check was introduced a while back to avoid having executable files
in the repository, but this check can be problematic sometimes because
of how it is written, namely when building the website, which causes a
lot of JS executable files to appear in the hierarchy, and in turn this
causes the shell expansion to fail because of the large number of
arguments.
Since this test is not necessary for Packer to build or test, and since
it implies that we have to maintain the whitelist regex, we remove it
from the Makefile.
Since bundled plugins will be removed in an upcoming version of Packer,
this commit adds a new warning message whenever a template uses one such
plugin.
This warning has been implemented on build, validate, console and the
inspect subcommands.
In addition to warning about the upcoming change and potential issue
this will cause, this warning message proposes solutions to the user so
they know what they'll have to do in order not to rely on those bundled
plugins later.
In HCL2, if a template contains a `required_plugins' block, but the
required plugins are not installed, we print a warning.
Prior to this commit, this was reported as an error once per missing
plugin, which was redundant.
This commit changes that by gathering all the missing plugins once, and
printing them as a bullet list, so the message isn't redundant anymore.
When the config file header was reworked, an erroneous link was
included and placed so close to the header that it was rendered verbatim
in the final documentation page.
By adding an extra empty line in between the anchor link and the header,
this renders correctly.
Packer checks a number of directories for plugins upon initialization,
with the introduction of multi-component plugins and underlying changes
to the Packer SDK the ordering changed slightly. These changes update
the related documentation to reflect the new ordering, and adds a plugin
loading ordering section to the docs to help users discover how plugin
loading works.
Include in this change are updates to the PACKER_CONFIG_DIR environment
variables to reflect the XDG base directory specification used as the
default Packer configuration directory layout.
* Update website/content/docs/configure.mdx
* Update external plugin documentation source
The Parallels plugin for Packer is now maintained by the Parallels 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-parallels for list of vendored plugins
Packer will try to discover installed plugins in all of the directories
defined by packer.KnowPluginFolders. In a previous release logic was
added to scan nested directories in order to load plugins installed by
`packer plugins install`. This change resulted in a nested directory
scan for each folder within the KnownPluginFolders slice.
This change reduces the nested directory scan to only the directories
where plugins would have been installed using `packer plugins install`
Remove the check-legacy-links-format.yml workflow. These checks are now included as part of our
content conformance checks that run on PRs with documentation content changes.
* docs: add a paragraph on fingerprint generation
Since version 1.9.0+ changed the way Packer generates fingerprints for
HCP Packer, we add a small paragraph to explain how it used to be
generated before, and how it changed in this version.
* Apply suggestions from code review
---------
Co-authored-by: Wilken Rivera <[email protected]>
With HCP supporting multi-projects now, Packer needs to take it into
account when picking a project from an organisation.
This commit adds two cases:
1. multiple projects are defined, none is supplied through
HCP_PROJECT_ID: in this case we will default to the oldest project
defined for the organisation.
2. we supply HCP_PROJECT_ID: in this case, we pick the project with the
corresponding ID, and use it for publishing metadata.
On HCP, multiproject support was GA'd recently, but Packer does not
support the feature yet.
To avoid clients being surprised if they encounter an error with this
feature enabled, we add an advisory related to this feature not being
supported for now, but planned for later.
This step removes community plugins from the Packer binary release. These plugins are being maintained and released independently of Packer and have become out of date. To ensure users are using the latest version of the plugins they are being removed in favor of the external plugin installation processes.
Prior to v1.8.6 a change to the release pipeline was introduced to
automatically set and bump product version information. In that change
the ldflags for striping debug symbols was removed resulting in binaries
with full debug symbols. Thus resulting in larger binary deliverables.
This change adds the missing ldflags back into the build pipeline.
Results for Packer 1.8.5
```
~> unzip ~/packer_1.8.5_linux_amd64.zip
~> go tool nm -size packer| c++filt
reading packer: no symbol section
reading packer: no symbols
```
Results for Packer 1.8.6
```
~> unzip ~/packer_1.8.6_linux_amd64.zip
~> go tool nm -size packer| c++filt | tail -n 10
8d97ac0 2816 D vendor/golang.org/x/text/unicode/norm.nfcSparseValues
8df2f60 6144 D vendor/golang.org/x/text/unicode/norm.nfcValues
8f96fc8 8 D vendor/golang.org/x/text/unicode/norm.nfkcData
8d985c0 2816 D vendor/golang.org/x/text/unicode/norm.nfkcIndex
8fa40a0 48 D vendor/golang.org/x/text/unicode/norm.nfkcSparse
8f4a3c0 24 D vendor/golang.org/x/text/unicode/norm.nfkcSparseOffset
8db5c00 3580 D vendor/golang.org/x/text/unicode/norm.nfkcSparseValues
8e48d60 12032 D vendor/golang.org/x/text/unicode/norm.nfkcValues
8f96fd0 8 D vendor/golang.org/x/text/unicode/norm.recompMap
8fe5bd0 12 D vendor/golang.org/x/text/unicode/norm.recompMapOnce
```
Closes#12392