upstream/packer
1
0
Fork 0
mirror of https://github.com/hashicorp/packer.git synced 2026-06-17 04:28:57 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
packer/packer_test/plugin_tests/install_test.go

107 lines
4.2 KiB
Go
Raw Permalink Normal View History

packer_test: make packer test suite modular Having only one test suite for the whole of Packer makes it harder to segregate between test types, and makes for a longer runtime as no tests run in parallel by default. This commit splits the packer_test suite into several components in order to make extension easier. First we have `lib`: this package embeds the core for running Packer test suites. This ships facilities to build your own test suite for Packer core, and exposes convenience methods and structures for building plugins, packer core, and use it to run a test suite in a temporary directory. Then we have two separate test suites: one for plugins, and one for core itself, the latter of which does not depend on plugins being compiled at all. This sets the stage for more specialised test suites in the future, each of which can run in parallel on different parts of the code.
2024-06-12 15:38:21 -04:00
package plugin_tests
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
import "github.com/hashicorp/packer/packer_test/common/check"
packer_test: make packer test suite modular Having only one test suite for the whole of Packer makes it harder to segregate between test types, and makes for a longer runtime as no tests run in parallel by default. This commit splits the packer_test suite into several components in order to make extension easier. First we have `lib`: this package embeds the core for running Packer test suites. This ships facilities to build your own test suite for Packer core, and exposes convenience methods and structures for building plugins, packer core, and use it to run a test suite in a temporary directory. Then we have two separate test suites: one for plugins, and one for core itself, the latter of which does not depend on plugins being compiled at all. This sets the stage for more specialised test suites in the future, each of which can run in parallel on different parts of the code.
2024-06-12 15:38:21 -04:00
func (ts *PackerPluginTestSuite) TestInstallPluginWithMetadata() {
packer_test: make PluginTestDir a structure In order for the creation of a temporary directory to install plugins into to be simpler to understand and use, we change how the directory is created, cleaned-up, and installs plugins into. Now, instead of a tuple of a string (path) and a cleanup function, we return a structure that comprises the test suite, and the temporary directory, along with methods to handle those steps independently.
2024-08-15 14:09:33 -04:00
tempPluginDir := ts.MakePluginDir()
defer tempPluginDir.Cleanup()
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
packer_test: amend installation with meta test The installation with a metadata part in the version for a plugin had one test that relied on the plugin directories being populated with packer plugins install --path. This could change in the future, while the command should remain functional, so we explicitely call it in the test instead of through the function that creates/populates a temp plugin dir.
2024-05-16 10:27:19 -04:00
ts.Run("install plugin with metadata in version", func() {
ts.PackerCommand().UsePluginDir(tempPluginDir).
packer_test: split BuildPackerPlugin in build/get The interface for building a plugin through the test suite was confusing, as it would build the plugin and return its path, cache the path for the version built, and return the path regardless if something was built or not. While in the current state this is harmless as builds are idempotent, since the state of the plugin package/module does not change, this will in the future as we introduce customisation techniques on the plugin's directory and files, making this double-use potentially dangerous. Furthermore, the current behaviour is unclear, as the function hides that caching mechanism, which could come as a surprise for users attempting to build a plugin for the duration of a test, while the built plugin is linked to the test suite being run, and not the unit test being evaluated. Therefore this commit changes the sequence in which plugins are built and used. Now the `CompilePlugin` function builds a plugin, and does not return its path anymore, instead terminating the tests immediately if they fail. In normal test usage, a new `GetPluginPath` function is introduced, which looks-up the path in the suite's cache, failing immediately if invoked before the plugin is built. With this change, it is heavily advised to build plugins when initialising the suite, then in the tests, the GetPluginPath function should be used to get a plugin's path for interacting with packer commands.
2024-08-14 16:12:53 -04:00
SetArgs("plugins", "install", "--path", ts.GetPluginPath(ts.T(), "1.0.0+metadata"), "github.com/hashicorp/tester").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustSucceed(), check.Grep("Successfully installed plugin", check.GrepStdout))
packer_test: amend installation with meta test The installation with a metadata part in the version for a plugin had one test that relied on the plugin directories being populated with packer plugins install --path. This could change in the future, while the command should remain functional, so we explicitely call it in the test instead of through the function that creates/populates a temp plugin dir.
2024-05-16 10:27:19 -04:00
})
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
ts.Run("metadata plugin installed must not have metadata in its path", func() {
ts.PackerCommand().UsePluginDir(tempPluginDir).
SetArgs("plugins", "installed").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustSucceed(), check.Grep("packer-plugin-tester_v1.0.0[^+]", check.GrepStdout))
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
})
ts.Run("plugin with metadata should work with validate", func() {
ts.PackerCommand().UsePluginDir(tempPluginDir).
SetArgs("validate", "./templates/simple.pkr.hcl").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustSucceed(), check.Grep("packer-plugin-tester_v1.0.0[^+][^\\n]+plugin:", check.GrepStderr))
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
})
ts.Run("plugin with metadata should work with build", func() {
ts.PackerCommand().UsePluginDir(tempPluginDir).
SetArgs("build", "./templates/simple.pkr.hcl").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustSucceed(), check.Grep("packer-plugin-tester_v1.0.0[^+][^\\n]+plugin:", check.GrepStderr))
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
})
}
packer_test: make packer test suite modular Having only one test suite for the whole of Packer makes it harder to segregate between test types, and makes for a longer runtime as no tests run in parallel by default. This commit splits the packer_test suite into several components in order to make extension easier. First we have `lib`: this package embeds the core for running Packer test suites. This ships facilities to build your own test suite for Packer core, and exposes convenience methods and structures for building plugins, packer core, and use it to run a test suite in a temporary directory. Then we have two separate test suites: one for plugins, and one for core itself, the latter of which does not depend on plugins being compiled at all. This sets the stage for more specialised test suites in the future, each of which can run in parallel on different parts of the code.
2024-06-12 15:38:21 -04:00
func (ts *PackerPluginTestSuite) TestInstallPluginWithPath() {
packer_test: make PluginTestDir a structure In order for the creation of a temporary directory to install plugins into to be simpler to understand and use, we change how the directory is created, cleaned-up, and installs plugins into. Now, instead of a tuple of a string (path) and a cleanup function, we return a structure that comprises the test suite, and the temporary directory, along with methods to handle those steps independently.
2024-08-15 14:09:33 -04:00
tempPluginDir := ts.MakePluginDir()
defer tempPluginDir.Cleanup()
packer_test: add test with both pre/meta in plugin To make sure we do scrub the metadata in the plugin name when installing it from a local binary, we add a test that does that installation with both alternatives: 1.0.0-dev and 1.0.0-dev+metadata, which should result in only one alternative being installed (the last one that succeeded).
2024-05-16 10:29:16 -04:00
ts.Run("install plugin with pre-release only", func() {
ts.PackerCommand().UsePluginDir(tempPluginDir).
packer_test: split BuildPackerPlugin in build/get The interface for building a plugin through the test suite was confusing, as it would build the plugin and return its path, cache the path for the version built, and return the path regardless if something was built or not. While in the current state this is harmless as builds are idempotent, since the state of the plugin package/module does not change, this will in the future as we introduce customisation techniques on the plugin's directory and files, making this double-use potentially dangerous. Furthermore, the current behaviour is unclear, as the function hides that caching mechanism, which could come as a surprise for users attempting to build a plugin for the duration of a test, while the built plugin is linked to the test suite being run, and not the unit test being evaluated. Therefore this commit changes the sequence in which plugins are built and used. Now the `CompilePlugin` function builds a plugin, and does not return its path anymore, instead terminating the tests immediately if they fail. In normal test usage, a new `GetPluginPath` function is introduced, which looks-up the path in the suite's cache, failing immediately if invoked before the plugin is built. With this change, it is heavily advised to build plugins when initialising the suite, then in the tests, the GetPluginPath function should be used to get a plugin's path for interacting with packer commands.
2024-08-14 16:12:53 -04:00
SetArgs("plugins", "install", "--path", ts.GetPluginPath(ts.T(), "1.0.0-dev"), "github.com/hashicorp/tester").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustSucceed(), check.Grep("Successfully installed plugin", check.GrepStdout))
packer_test: add test with both pre/meta in plugin To make sure we do scrub the metadata in the plugin name when installing it from a local binary, we add a test that does that installation with both alternatives: 1.0.0-dev and 1.0.0-dev+metadata, which should result in only one alternative being installed (the last one that succeeded).
2024-05-16 10:29:16 -04:00
})
ts.Run("install same plugin with pre-release + metadata", func() {
ts.PackerCommand().UsePluginDir(tempPluginDir).
packer_test: split BuildPackerPlugin in build/get The interface for building a plugin through the test suite was confusing, as it would build the plugin and return its path, cache the path for the version built, and return the path regardless if something was built or not. While in the current state this is harmless as builds are idempotent, since the state of the plugin package/module does not change, this will in the future as we introduce customisation techniques on the plugin's directory and files, making this double-use potentially dangerous. Furthermore, the current behaviour is unclear, as the function hides that caching mechanism, which could come as a surprise for users attempting to build a plugin for the duration of a test, while the built plugin is linked to the test suite being run, and not the unit test being evaluated. Therefore this commit changes the sequence in which plugins are built and used. Now the `CompilePlugin` function builds a plugin, and does not return its path anymore, instead terminating the tests immediately if they fail. In normal test usage, a new `GetPluginPath` function is introduced, which looks-up the path in the suite's cache, failing immediately if invoked before the plugin is built. With this change, it is heavily advised to build plugins when initialising the suite, then in the tests, the GetPluginPath function should be used to get a plugin's path for interacting with packer commands.
2024-08-14 16:12:53 -04:00
SetArgs("plugins", "install", "--path", ts.GetPluginPath(ts.T(), "1.0.0-dev+metadata"), "github.com/hashicorp/tester").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustSucceed(), check.Grep("Successfully installed plugin", check.GrepStdout))
packer_test: add test with both pre/meta in plugin To make sure we do scrub the metadata in the plugin name when installing it from a local binary, we add a test that does that installation with both alternatives: 1.0.0-dev and 1.0.0-dev+metadata, which should result in only one alternative being installed (the last one that succeeded).
2024-05-16 10:29:16 -04:00
})
ts.Run("list plugins, should only report one plugin", func() {
ts.PackerCommand().UsePluginDir(tempPluginDir).
SetArgs("plugins", "installed").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustSucceed(),
check.Grep("plugin-tester_v1.0.0-dev[^+]", check.GrepStdout),
check.GrepInverted("plugin-tester_v1.0.0-dev\\+", check.GrepStdout),
check.LineCountCheck(1))
packer_test: add test with both pre/meta in plugin To make sure we do scrub the metadata in the plugin name when installing it from a local binary, we add a test that does that installation with both alternatives: 1.0.0-dev and 1.0.0-dev+metadata, which should result in only one alternative being installed (the last one that succeeded).
2024-05-16 10:29:16 -04:00
})
}
packer_test: make packer test suite modular Having only one test suite for the whole of Packer makes it harder to segregate between test types, and makes for a longer runtime as no tests run in parallel by default. This commit splits the packer_test suite into several components in order to make extension easier. First we have `lib`: this package embeds the core for running Packer test suites. This ships facilities to build your own test suite for Packer core, and exposes convenience methods and structures for building plugins, packer core, and use it to run a test suite in a temporary directory. Then we have two separate test suites: one for plugins, and one for core itself, the latter of which does not depend on plugins being compiled at all. This sets the stage for more specialised test suites in the future, each of which can run in parallel on different parts of the code.
2024-06-12 15:38:21 -04:00
func (ts *PackerPluginTestSuite) TestInstallPluginPrerelease() {
packer_test: split BuildPackerPlugin in build/get The interface for building a plugin through the test suite was confusing, as it would build the plugin and return its path, cache the path for the version built, and return the path regardless if something was built or not. While in the current state this is harmless as builds are idempotent, since the state of the plugin package/module does not change, this will in the future as we introduce customisation techniques on the plugin's directory and files, making this double-use potentially dangerous. Furthermore, the current behaviour is unclear, as the function hides that caching mechanism, which could come as a surprise for users attempting to build a plugin for the duration of a test, while the built plugin is linked to the test suite being run, and not the unit test being evaluated. Therefore this commit changes the sequence in which plugins are built and used. Now the `CompilePlugin` function builds a plugin, and does not return its path anymore, instead terminating the tests immediately if they fail. In normal test usage, a new `GetPluginPath` function is introduced, which looks-up the path in the suite's cache, failing immediately if invoked before the plugin is built. With this change, it is heavily advised to build plugins when initialising the suite, then in the tests, the GetPluginPath function should be used to get a plugin's path for interacting with packer commands.
2024-08-14 16:12:53 -04:00
pluginPath := ts.GetPluginPath(ts.T(), "1.0.1-alpha1")
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
packer_test: make PluginTestDir a structure In order for the creation of a temporary directory to install plugins into to be simpler to understand and use, we change how the directory is created, cleaned-up, and installs plugins into. Now, instead of a tuple of a string (path) and a cleanup function, we return a structure that comprises the test suite, and the temporary directory, along with methods to handle those steps independently.
2024-08-15 14:09:33 -04:00
pluginDir := ts.MakePluginDir()
defer pluginDir.Cleanup()
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
ts.Run("try install plugin with alpha1 prerelease - should fail", func() {
ts.PackerCommand().UsePluginDir(pluginDir).
SetArgs("plugins", "install", "--path", pluginPath, "github.com/hashicorp/tester").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustFail(), check.Grep("Packer can only install plugin releases with this command", check.GrepStdout))
test: add installation tests to acceptance tests 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.
2024-05-03 15:41:36 -04:00
})
}
test: add more tests for Packer core
2024-05-07 16:26:20 -04:00
packer_test: make packer test suite modular Having only one test suite for the whole of Packer makes it harder to segregate between test types, and makes for a longer runtime as no tests run in parallel by default. This commit splits the packer_test suite into several components in order to make extension easier. First we have `lib`: this package embeds the core for running Packer test suites. This ships facilities to build your own test suite for Packer core, and exposes convenience methods and structures for building plugins, packer core, and use it to run a test suite in a temporary directory. Then we have two separate test suites: one for plugins, and one for core itself, the latter of which does not depend on plugins being compiled at all. This sets the stage for more specialised test suites in the future, each of which can run in parallel on different parts of the code.
2024-06-12 15:38:21 -04:00
func (ts *PackerPluginTestSuite) TestRemoteInstallWithPluginsInstall() {
packer_test: add SkipNoAcc function The SkipNoAcc function on PackerTestSuite allows to mark a test run as not to be run every time we run `make test`, but only when PACKER_ACC=1 is set in the environment. This allows us to skip executing tests that are either long-running, or that depend on external dependencies (typically Github), which have a higher potential to fail on a normal run of Packer tests.
2024-06-12 15:54:03 -04:00
ts.SkipNoAcc()
packer_test: make PluginTestDir a structure In order for the creation of a temporary directory to install plugins into to be simpler to understand and use, we change how the directory is created, cleaned-up, and installs plugins into. Now, instead of a tuple of a string (path) and a cleanup function, we return a structure that comprises the test suite, and the temporary directory, along with methods to handle those steps independently.
2024-08-15 14:09:33 -04:00
pluginPath := ts.MakePluginDir()
defer pluginPath.Cleanup()
test: add more tests for Packer core
2024-05-07 16:26:20 -04:00
ts.Run("install latest version of a remote plugin with packer plugins install", func() {
ts.PackerCommand().UsePluginDir(pluginPath).
SetArgs("plugins", "install", "github.com/hashicorp/hashicups").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustSucceed())
test: add more tests for Packer core
2024-05-07 16:26:20 -04:00
})
packer_test: add remote install with pre-rel test Remotely installing plugins with a pre-release as part of the constraint is unsupported by Packer, and should error if that happens. This test makes sure that this gets treated as an error if that's the case, even before attempting to connect to the source.
2024-05-29 14:59:45 -04:00
}
packer_test: make packer test suite modular Having only one test suite for the whole of Packer makes it harder to segregate between test types, and makes for a longer runtime as no tests run in parallel by default. This commit splits the packer_test suite into several components in order to make extension easier. First we have `lib`: this package embeds the core for running Packer test suites. This ships facilities to build your own test suite for Packer core, and exposes convenience methods and structures for building plugins, packer core, and use it to run a test suite in a temporary directory. Then we have two separate test suites: one for plugins, and one for core itself, the latter of which does not depend on plugins being compiled at all. This sets the stage for more specialised test suites in the future, each of which can run in parallel on different parts of the code.
2024-06-12 15:38:21 -04:00
func (ts *PackerPluginTestSuite) TestRemoteInstallOfPreReleasePlugin() {
packer_test: add SkipNoAcc function The SkipNoAcc function on PackerTestSuite allows to mark a test run as not to be run every time we run `make test`, but only when PACKER_ACC=1 is set in the environment. This allows us to skip executing tests that are either long-running, or that depend on external dependencies (typically Github), which have a higher potential to fail on a normal run of Packer tests.
2024-06-12 15:54:03 -04:00
ts.SkipNoAcc()
packer_test: make PluginTestDir a structure In order for the creation of a temporary directory to install plugins into to be simpler to understand and use, we change how the directory is created, cleaned-up, and installs plugins into. Now, instead of a tuple of a string (path) and a cleanup function, we return a structure that comprises the test suite, and the temporary directory, along with methods to handle those steps independently.
2024-08-15 14:09:33 -04:00
pluginPath := ts.MakePluginDir()
defer pluginPath.Cleanup()
packer_test: add remote install with pre-rel test Remotely installing plugins with a pre-release as part of the constraint is unsupported by Packer, and should error if that happens. This test makes sure that this gets treated as an error if that's the case, even before attempting to connect to the source.
2024-05-29 14:59:45 -04:00
ts.Run("try to init with a pre-release constraint - should fail", func() {
ts.PackerCommand().UsePluginDir(pluginPath).
SetArgs("init", "templates/pre-release_constraint.pkr.hcl").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustFail(),
check.Grep("Invalid version constraint", check.GrepStdout),
check.Grep("Unsupported prerelease for constraint", check.GrepStdout))
packer_test: add remote install with pre-rel test Remotely installing plugins with a pre-release as part of the constraint is unsupported by Packer, and should error if that happens. This test makes sure that this gets treated as an error if that's the case, even before attempting to connect to the source.
2024-05-29 14:59:45 -04:00
})
test: add more tests for Packer core
2024-05-07 16:26:20 -04:00
packer_test: add remote install with pre-rel test Remotely installing plugins with a pre-release as part of the constraint is unsupported by Packer, and should error if that happens. This test makes sure that this gets treated as an error if that's the case, even before attempting to connect to the source.
2024-05-29 14:59:45 -04:00
ts.Run("try to plugins install with a pre-release version - should fail", func() {
test: add more tests for Packer core
2024-05-07 16:26:20 -04:00
ts.PackerCommand().UsePluginDir(pluginPath).
packer_test: add remote install with pre-rel test Remotely installing plugins with a pre-release as part of the constraint is unsupported by Packer, and should error if that happens. This test makes sure that this gets treated as an error if that's the case, even before attempting to connect to the source.
2024-05-29 14:59:45 -04:00
SetArgs("plugin", "install", "github.com/hashicorp/hashicups", "1.0.2-dev").
packer_test: rename/split lib into common/check The lib name for the common components for writing packer_test suites was not clear, and did not follow the convention established in Packer core and plugins. Therefore this commit does two things: first the lib is renamed into common as to follow this convention, and clearly document which components are common to all tests. Also checkers are placed in a subpackage of common, common/check, so that it is clearer what is meant to be used as checks for a command's execution status after it's been run, as part of Assert.
2024-08-15 10:05:27 -04:00
Assert(check.MustFail(),
check.Grep("Unsupported prerelease for constraint", check.GrepStdout))
packer_test: add test for plugin remove with path
2024-05-15 14:16:31 -04:00
})
}
Reference in a new issue Copy permalink