packer

Commit Graph

Author	SHA1	Message	Date
dependabot[bot]	3c898a145e	build(deps): bump golang.org/x/oauth2 Bumps [golang.org/x/oauth2](https://github.com/golang/oauth2) from 0.13.0 to 0.27.0. - [Commits](https://github.com/golang/oauth2/compare/v0.13.0...v0.27.0) --- updated-dependencies: - dependency-name: golang.org/x/oauth2 dependency-version: 0.27.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>	6 months ago
dependabot[bot]	1d834d5d9a	build(deps): bump github.com/ulikunitz/xz Bumps [github.com/ulikunitz/xz](https://github.com/ulikunitz/xz) from 0.5.10 to 0.5.14. - [Commits](https://github.com/ulikunitz/xz/compare/v0.5.10...v0.5.14) --- updated-dependencies: - dependency-name: github.com/ulikunitz/xz dependency-version: 0.5.14 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>	6 months ago
anshulSharma	f1f02ee505	doc changes about CRT migration (#13433 ) * doc changes about CRT migration * docs changes suggested * docs changes suggested * docs changes suggested * typo fix * typo fix	7 months ago
Jenna Goldstrich	f16ca7fa03	Bump /x/net and /x/crypto in plugin tester and main go.mod	10 months ago
Lucas Bajolet	56400f27cb	packer_test: add gob/pb test suite With the draft to support both gob and protobuf as serialisation formats for Packer, along with the SDK changes that propel them, we add a series of tests that make sure the logic that picks which protocol is solid and functional. These tests rely on building several versions of the tester plugin, with and without protobuf support, to then install them in the tests as needed to test the logic of Packer using packer build with them, and templates that require multiple plugins.	1 year ago
dependabot[bot]	3826a94758	build(deps): bump golang.org/x/net in /packer_test/common/plugin_tester Bumps [golang.org/x/net](https://github.com/golang/net) from 0.23.0 to 0.33.0. - [Commits](https://github.com/golang/net/compare/v0.23.0...v0.33.0) --- updated-dependencies: - dependency-name: golang.org/x/net dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>	1 year ago
dependabot[bot]	38f081c9ed	build(deps): bump golang.org/x/crypto Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.21.0 to 0.31.0. - [Commits](https://github.com/golang/crypto/compare/v0.21.0...v0.31.0) --- updated-dependencies: - dependency-name: golang.org/x/crypto dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>	1 year ago
Lucas Bajolet	5ff0f146c6	packer_test: introduce global compilation queue Compiling plugins was originally intended to be an idempotent operation. This however starts to change as we introduce build customisations, which have the unfortunate side-effect of changing the state of the plugin directory, leading to conflicts between concurrent compilation jobs. Therefore to mitigate this problem, this commit changes how compilation jobs are processed, by introducing a global compilation queue, and processing plugins' compilation one-by-one from this queue. This however makes such requests asynchronous, so test suites that require plugins to be compiled will now have to wait on their completion before they can start their tests. To this effect, we introduce one more convenience function that processes those errors, and automatically fails the test should one compilation job fail for any reason.	1 year ago
Lucas Bajolet	b6b0a081ad	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.	1 year ago
Lucas Bajolet	11c238b9eb	packer_test: add FileGlob checker When trying to validate that a particular file exists after a run of Packer in a test suite, we can use the FileExists checker that we provide as part of the gadgets we added for the acceptance test suites. This approach works well, but only if we can extract a file name reliably from the output of Packer core, or if we know what to look for exactly beforehand. For other cases with a generated name however, the FileExists checker is not enough, and therefore to accomodate for those cases, we are introducing a new checker for this purpose: FileGlob. FileGlob, as its name suggests, runs a glob expression on the filesystem, and returns an error if no match was found regarding this glob expression.	1 year ago
Lucas Bajolet	44a94911da	packer_test: add FileExists checker Some tests will create files and directories as part of the execution path for Packer, and we need a way to check this, so this commit adds a new file gadget to do those checks after a command executes.	1 year ago
Lucas Bajolet	3c449430e1	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.	1 year ago
Lucas Bajolet	31b6109430	packer_test: hide run and introduce Output When using a PackerCommand, the Run function was made public as a way to access the contents of an execution. This was clumsy as it had too many responsabilities, and was not needed strictly as Assert was performing the executions, as many times as required. This could introduce cases in which one run as spent by the caller, then the remainder were executed through Assert. Therefore, we change this convention. Now, run is private to the type, and only through Assert can a command be executed. If a test needs access to a command's output, stderr, or error, it can do so through the Output function, which requires Assert to be called first.	1 year ago
Lucas Bajolet	71169416db	packer_test: add func to change assert behaviour When a command asserts its output with checkers, by default it will register errors through a t.Errorf. While this works, in some cases we would want to stop execution immediately if a function's Assert fails, as the rest of the test may depend on the assertion being valid. In the current state, this means either getting the result of the run to check if an error was returned (not fully reliable as if the command was run multiple times, and the last run succeeded, we won't get an error), or relying on t.IsFailed() (completely reliable). Instead, we introduce a new function on packerCommand, that lets users change how Assert behaves, so that if an error was reported, instead of logging the error and flagging the test as failed, we can use t.Fatalf, so that the test immedately fails and stops execution.	1 year ago
Lucas Bajolet	35b2317ef3	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.	1 year ago

15 Commits (e703473a9baf87dfd62ea1c9a3dc6200decd5e32)