The NewPluginBuildConfig function was essentially a shortcut to
`version.Must(version.NewSemver(v))', which is superfluous at this
point, we can directly pass the version string to BuildSimplePlugin and
let that function do the creation/check.
Since the MakePluginDir function takes the TestSuite as receiver, we
don't need to additionally pass in a reference to testing.T, since the
test suite already contains one instance, and offers a function to get
it from.
The PluginVersionConfig structure was first introduced when building
the early versions of the test package, but it was an unnecessary
abstraction over go-version.Version.
So we remove that structure definition, and instead we directly use the
version for building those temporary plugins.
The CopyFile function is essentially a go recreation of the `cp'
command, which copies one file from a source path to a destination
directory or file.
This can be used for several tests in the future.
When creating a temporary plugin directory, we had to build a cleanup
function, which could be as simple as `os.Mkdirall` without any kind of
warning that a directory failed to be cleaned-up, or we could do some
more work in order to report the possible issues around this.
That code would quickly be redundant, as there's not a ton of
variability in the code that can be written for this step, so we
abstract it through a pre-defined cancellation function which can be
safely defer invoked.
Creating the Name() function for every gadget we have is superfluous a
bit, as we're essentially parroting the name of the test itself as
implementation for the function.
So instead of requiring every checker implements `Name', we now default
to returning the type name, but if the Name function exists for the
checker, we invoke it and return the value for that function.
This allows us to only define the function where needed, and not
systematically.
Since compiling plugins is quick, but each invocation still takes a bit
of time, we run those compilation jobs in parallel to shave of a couple
seconds from a test run.
Acceptance testing, i.e. running Packer core commands in a controlled
environment and ensuring the behaviour is consistent to what we
expect/document, is not something we have a robust and usable framework
for at the moment.
This commit is a proposal for a base testing framework of the sort, that
is meant to be shipped with packer core, and which will eventually host
most of the tests we currently do in command where we mock an
environment.
The mini plugin implemented here is a minimal Packer plugin that we use
for acceptance testing Packer core.
There's a few components exposed so we can write templates using it, and
make sure Packer interprets it all as it should, and runs/errors as we
expect it.
* docs: add plugin loading spec documentation
The logic for discovering and loading plugins is not well documented on
the current documentation.
This causes issues for users that have to troubleshoot why a particular
plugin cannot be found or installed, so this commit adds a specification
document, detailing what are Packer's expectations when it comes to
discovering plugins.
* Apply suggestions from code review
* Update plugin loading specification navbar
---------
Co-authored-by: Wilken Rivera <[email protected]>
The acceptance tests were failing to be run on CI as the linter reported
some typecheck mismatches.
This could be due to an older version of golangci-lint running on them,
so we bump it to v1.54.0, empirically determined as when the lint
started being adequately reported.
Both linters are not supported anymore and trigger warnings every time
we try to lint our code.
To not see those warnings anymore, we remove them from the
configuration.
Since we released 1.11.0 today, we need to have main point to the next
minor release of Packer so CI succeeds, otherwise we get an unexpected
output for the version being out-of-date.
When remotely installing a plugin, constraints are used by Packer to
determine which version of a plugin to install.
These constraints can be arbitrarily complex, including operators and
ranges in which to look for valid versions.
However, the versions specified in those constraints should always be
final releases, and not a pre-release since we don't explicitly support
remotely installing pre-releases.
This commit therefore addds checks to make sure these are reported ASAP,
even before the source is contacted to list releases and picking one to
install.
The global `PACKER_CONFIG` config file was already deprecated from
Packer core, but now with 1.11.0 since we remove support for
mono-component plugins, we are also removing the capability for that
config file to declare them.
Instead of silently not using those, Packer will now error with a
message pointing to the web docs on how to manage their plugins with the
updated workflows for Packer 1.11 and above.
Compared to Terraform, Packer was lacking a capability to encode/decode
strings to/from base64-encoded text encoded with another encoding.
This could be problematic in some cases, mainly when working with
Windows, as most of the OS uses UTF-16LE as its standard encoding for
many operations.
Therefore, we take a page from Terraform here, and add those functions
to what Packer supports in an HCL2 context.
When a server returns a code that is not 200, we error in the current
state.
This is not conformant to the HTTP norm, as anything in the 2xx range is
considered a success, so the datasource should not error in this case.
Therefore, this commit fixes the condition in which we report an error,
so that anything in the 2xx range is now considered a success by the
datasource.
When updating the docs in prevision for Packer 1.11.0, we changed the
templates that show how plugins are installed/discovered with commands
like packer init.
While doing so, a template had its component renamed to coolcloud, but
the following prose did not change, making the text inconsistent.
Since there are other mentions of myawesomecloud in the codebase, we
choose to settle on this one for that example too.
When Discovering plugins installed through the `Discover` function, we
use the base name of the plugin binary we discovered preliminarly, then
we match its name against a regex to extract the prefix for the plugin's
components.
Extracting the base path used to be done with `path.Base`, which while
working perfectly on UNIX systems, does not on Windows as it uses `\\`
as their path separator.
To circumvent this problem, we use the `filepath` package to extract the
base name of the plugin instead, making the discovery logic work again
on Windows.
Listing installed plugins on Windows requires the extension to be set in
the ListOptions, otherwise they are not discovered.
While working on the discovery code, and consolidating it in a single
location, we've forgotten to pass the argument to ListInstallations, so
that makes it impossible to automatically discover installed components
on Windows.
This commit fixes this issue for the plugins required, and the general
discovery process during build/validate.
If a plugin is installed in the PACKER_PLUGIN_PATH, and its version
contains metadata, we reject it. This is because metadata is free-form
data, which could then make it possible to have multiple conflicting
versions of a plugin installed, so we don't support it and explicitely
reject plugins like those.
A valid plugin with metadata in its version information should be
installed without its metadata part, so there can only be one variant of
the plugin installed at a specific version.
Since the plugins install subcommand can install both remotely and
locally sourced plugins, we update the documentation for it on the
web-docs to reflect this change.
The ParsePluginSource function can be invoked from either a HCL2 context
(when parsing a required_plugins block), or from the command-line
itself.
While in the first context a hcl.Diagnostics is coherent, in case the
source to parse is a command-line argument, for example when installing
or removing a plugin, the error message cannot have an HCL context,
leading to errors that are incorrectly prefixed by a <nil> string dure
to the lack of a reference to attach the diagnostic to.
Therefore, in order to fix this behaviour, the logic that parses plugin
sources now returns an error, and attaching the error to an HCL subject
is done independently, if needed.
When specifying/installing plugins, a source URI is required for Packer
to be able to locate or install a plugin to the local plugin hierarchy.
The plugin hierarchy is based on the plugin source, where each component
in this hierarchy will become a directory.
In order to avoid sources with too many levels of nesting, causing a lot
of mkdirs, we limit the number of sources to 16 in this commit, this
should be long enough for most of our users.
Since we're changing how packer manages plugin installation with 1.11.0,
we reflect those changes to the website documentation.
Now, we only describe the packer init and packer plugins install
commands, along with the `--path` flag for installing from a local
source.
The explanations of how packer discovers and picks which version of a
plugin to load are also included, along with the list of constraints
that determine whether a plugin can be considered or not to be loadable.
Lucas Bajolet
Lucas BajoletandWilken Rivera
David Guo
hashicorp-tsccr[bot]
Alex Boutin
komisan19
IAMDAVID0920
Steven Kalt
dependabot[bot]
Estelle PoulinandWilken Rivera