The ExpectedInstalledName function returns the expected full name of a
plugin binary after it's installed.
This is used for tests that need to copy the binary to some place before
they can run commands and ensure the logic for managing plugins conforms
to the docs/specs.
Since sometimes we want to check for matches, and sometimes we want to
check for a lack of match, we add one more option for the Grep gadget:
inverse.
This essentially replicates `grep -v`, and will succeed only if the
regex provided did NOT match on the requested streams.
This commit adds a few scenarios of plugin installations to the test
suite, in order to document and ensure we behave appropriately when
installing pre-releases/metadata.
When building the temporary plugin directory for a test, we didn't check
that the LoadPluginVersion call succeeded and returned a path, which
may cause errors down the line when attempting to install the plugin.
To avoid this problem, we do the check at that time, and immediately
fail if a plugin isn't found.
MakePluginDir used to only load plugins that were precompiled at the
start of the tests, but now when invoked with any list of plugins, this
will attempt to compile plugins one-by-one, so we don't need to modify
the tests in several places when running tests.
There's still value in compiling the plugins in advance though: as they
run in parallel, they all get compiled at once, so we shave off a few
seconds from the test run.
Calling BuildSimplePlugin for a particular version used to mean that we
had to build it regardless of if it was previously done or not.
This commit changes this behaviour so that it checks first that the
plugin wasn't pre-compiled, and if it was, we immediately return.
When running "Assert" on a packer command, we run a series of checkers
on the command's output/error code, which provoke test failures if they
fail.
Panic checking used to be part of Run, but in the end this would make
more sense to have that as a regular checker if asserting the results of
a packer command, so that's the approach we adopt with this commit.
When running a PackerCommand for acceptance tests, we generally run the
test on a temporary plugin directory, populated by test plugins.
Setting that temporary directory means we need to set the environment
variable, which while it could be easier with a constant for the name
for example, isn't too straightforward.
Therefore for those tests we add a new function for PackerCommand so
that it automatically sets that envvar for the current command.
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.
Lucas Bajolet
Lucas BajoletandWilken Rivera
David Guo
hashicorp-tsccr[bot]
Alex Boutin
komisan19
IAMDAVID0920
Steven Kalt
dependabot[bot]