5 Commits (896d0e02b0685e0187ef8dc601433dd13ba41c9f)

Author	SHA1	Message	Date
Lucas Bajolet	896d0e02b0	packer_test: add build customisation capabilities ... When building a plugin, we may want some customisation capabilities beyond changing the version/pre-release/metadata, and instead run commands or change files on the filesystem. To do so, we introduce functions under the BuildCustomisation type, which have two responsabilities: changing the current state of the plugin's directory, and cleaning up afterwards. These customisations are passed as parameters to the BuildSimplePlugin function, and are called one-by-one, deferring their cleanup after the build process is finished. A first implementation of such a customisation is added with this commit, in order to change the version of a module that the plugin depends on, which we'll use to change the version of the plugin SDK in order to test how Packer behaves with different versions of the SDK for a single plugin.	2 years ago
Lucas Bajolet	6b158c5c24	packer_test: move some plugin functions to fs.go ... As a small reorganisation attempt, this commit moves some file-system oriented functions from plugin.go into its own file so they are more logically grouped.	2 years ago
Lucas Bajolet	96b4ae4767	packer_test: move BuildSimplePlugin to plugin.go ... In terms of organisation, we keep functions that interact with plugins into its own file, therefore the function that build plugin versions should really be in plugin.go, not in suite.go.	2 years ago
Lucas Bajolet	2fe11fb967	packer_test: move compiledPlugins to attribute ... The compiledPlugins map used to be a global variable, which can be problematic as we move to independent test suites, since those test suites run in the same process space, the global variable could point to now deleted plugin versions/paths in separate suites, which would make tests fail with random errors. To avoid this, the map is now scoped to the test suite, and a new copy is created lazily if used by the test suite.	2 years ago
Lucas Bajolet	9e4452329f	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.	2 years ago