mirror of
https://github.com/hashicorp/packer.git
synced 2026-10-12 17:22:01 -04:00
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.
20 lines
937 B
Markdown
20 lines
937 B
Markdown
## The Example Folder
|
|
|
|
This folder must contain a fully working example of the plugin usage. The example must define the `required_plugins`
|
|
block. A pre-defined GitHub Action will run `packer init`, `packer validate`, and `packer build` to test your plugin
|
|
with the latest version available of Packer.
|
|
|
|
The folder can contain multiple HCL2 compatible files. The action will execute Packer at this folder level
|
|
running `packer init -upgrade .` and `packer build .`.
|
|
|
|
If the plugin requires authentication, the configuration should be provided via GitHub Secrets and set as environment
|
|
variables in the [test-plugin-example.yml](/.github/workflows/test-plugin-example.yml) file. Example:
|
|
|
|
```yml
|
|
- name: Build
|
|
working-directory: ${{ github.event.inputs.folder }}
|
|
run: PACKER_LOG=${{ github.event.inputs.logs }} packer build .
|
|
env:
|
|
AUTH_KEY: ${{ secrets.AUTH_KEY }}
|
|
AUTH_PASSWORD: ${{ secrets.AUTH_PASSWORD }}
|
|
``` |