This change temporarily renames the type of the packer-image-iteration
datasource to prevent it from being automatically registered by the
Packer plugin tooling. The datasource is fully functional, but not quite
ready for full usage. It will be updated in a future release.
* Update handling of registry artifacts
This change uses the github.com/hashicorp/packer-plgin-sdk/packer/registryimage for querying
Artifact State for HCP Registry Image metadata. To handle the conversion
of the RPC response, mapstructure was introduced to conversion state
data into an registryimage.Image before publishing to a image bucket.
* Update to use registry image from packersdk
* Rename internal registry service pkg
* Update vendored plugins to latest version
* The latest release of Amazon, GoogleCompute, and Azure have support
for publishing images to the HCP Packer registry.
create a null data source for testing. We can choose to document if we want to, but it's a convenience for us
add a test to catch cyclic datasource dependency, update tests to include out of order data sources, and update the code to clean up the returned diagnostics generated from the recursive evaluation
PR review comments
* fix typo
* hcl2_upgrade: special case linux_options and network_interface to block instead of maps
* Update hcl2_upgrade_test.go
* Update hcl2_upgrade_test.go
remove unused code
* hcl2_upgrade: support strftime too (#11220)
* hcl2_upgrade strftime function
* create legacy_strftime.mdx
* Add working registry pkg
* Add custom error for handling the loading of PAR environment variables
* Working Publish to Build, with proper error handling for bucket names
* Update hcp-sdk-go to use branch instead of mod replace directive
* Update Packer build status configuration
* Add support for HCP_PACKER_BUILD_FINGERPRINT env
* Add support for publishing one or more PARtifacts from a single build
* add git shas to this branch
* Add ability to set provider name if available
* Add working RegistryBuilder type
* Add RegistryPostProcessor as wrapper post-processor
* When in PAR mode a empty RegistryPostProcessor is added to the end of
the post-processor list to publish all final image data.
* Add support for updating a build from PAR that is not in a DONE state
* Fix a small issue with creation the initial builds for an empty
iteration.
* Add PAR URL to post-processor display
* Implement hcp_packer_registry block (#11168)
* Update vendored Amazon plugin to v1.0.1-dev
* Fix panic when running a Packer registry build in a clean directory
* Remove the publishing of post-processor metadata from the registry
post-processor.
* Remove metadata add from registry_builder
* Update registry builder to skip a build that was found to be DONE
Co-authored-by: Megan Marsh <megan@hashicorp.com>
Co-authored-by: Sylvia Moss <moss@hashicorp.com>
* Remove Azure plugin components and docs
* Add Azure plugin to vendored_plugins
* Updates Azure to use remote plugin docs
* Revendor packer-plugin-azure at v0.0.2
* Update to new version of the Packer plugin SDK v0.2.1
* Update to the official version of go-getter@v2.0.0
* Update salt provisioner to use new go-getter API
* Update vendored plugins to working versions
This changes fixes an issue with the go.sum for the Azure plugin.
It also revendors the plugins for puppet, chef, and ansible as v0.0.1
of those plugins where not usable.
* use vendored scaleway plugin
* wipe out scaleway
* vendor vendors
* use remote docs
* go get github.com/hashicorp/packer-plugin-scaleway@v0.0.1
* empty commit
This :
* allows to have a `build.dynamic` block
* add tests
* makes sure to show a correct message when a source was not found
* display only name of source (instead of a weird map printout)
* use a "Did you mean %q" feature where possible
Because dynamic blocks need all variables to be evaluated and available, I moved parsing of everything that is not a variable to "after" variables are extrapolated. Meaning that dynamic block get expanded in the `init` phase and then only we start interpreting HCL2 content.
After #10819fix#10657
* used components that don't have a required_plugin block will make Packer 'implicitly' require those. These components are manually selected and commented for now.
* add tests
* docs
This change adds a new set of maps for builders, provisioners, and
post-processors that store reference to components that were once part
of Packer and are now vendored. This file acts as a single place for
defining this vendored components, which are then merged into the main
components maps to be used in Packer.
Quick test to ensure the exoscale-import post-processor is still loaded
```
// Validate that exoscale-import is in the know post-procoessors list
~> packer.test build docker_centos_shell_provisioner.pkr.hcl
Error: Unknown post-processor type "badlynamed-import"
on docker_centos_shell_provisioner.pkr.hcl line 18:
(source code not available)
known post-processors: [ucloud-import digitalocean-import docker-push
googlecompute-export manifest vsphere-template docker-tag vsphere checksum
docker-import exoscale-import yandex-export compress googlecompute-import
yandex-import vagrant-cloud alicloud-import amazon-import artifice shell-local
docker-save vagrant]
// Validate that exoscale-import get loaded
~> packer.test build docker_centos_shell_provisioner.pkr.hcl
Error: Failed preparing post-processor-block "exoscale-import" ""
on docker_centos_shell_provisioner.pkr.hcl line 18:
(source code not available)
4 error(s) occurred:
* api_key must be set
* api_secret must be set
* image_bucket must be set
* template_zone must be set
==> Wait completed after 2 microseconds
==> Builds finished but no artifacts were created.
```
This change removes the generation of command/plugin.go so that plugin
registration can be managed manually. As we begin to break out plugins
we will need to begin modifying this file, possibly with stubs to allow
for the removal of plugins without breaking Packer's backwards
compatibility with 1.7.0. After 1.8.0 is released we should be able to
revet these changes so that we can continue to generate the plugin
file for those plugins core to Packer.
* fix random nil pointer dereference I found while debugging hcl2_upgrade issues
* fix hcl2_upgrade command by creating passthroughs for all text template fields
* show error as to why plugin discovery failed
* allow to run more manual tests after a plugin installation
* test that a freshly installed external plugin can run
This adds the new `required_plugins` block to be nested under the packer block.
Example:
```hcl
packer {
required_plugins {
aws = {
version = ">= 2.7.0"
source = "azr/aws"
}
azure = ">= 2.7.0"
}
}
```
For example on darwin_amd64 Packer will install those under :
* "${PACKER_HOME_DIR}/plugin/github.com/azr/amazon/packer-plugin-amazon_2.7.0_x5.0_darwin_amd64"
* "${PACKER_HOME_DIR}/plugin/github.com/hashicorp/azure/packer-plugin-azure_2.7.0_x5.0_darwin_amd64_x5"
+ docs
+ tests
* change beta tag
* remove beta tag from hcl2_upgrade comment
* add a partial to describe the legacy json limitations
* exclude legacy category from templates until it is deployed to the website
* move maps of plugins back in core
* go mod vendor
* more fixes
* fix imports
* Update core_test.go
* fix build
* more fixes
* more fixes
* up vendors after fixing sdk
* Update post_processor_mock.hcl2spec.go
* Leave implementatino of MapOf in the sdk for plugi tests
Other wise use the interface
* go mod tidy
* add MapOfDatasource type too
* HCL2: Test that the packer block passes in packer validate
* HCL2: Test invalid packer blocks are invalid
* docs: state from which version the packer block is available
* Add packer fmt command
This change adds a new command that allows users to format one or more
HCL2 Packer configuration template files.
Related to: #9174
* command/fmt: Add check flag
Packer's fmt command now supports a check flag that will output the name
of any file that would be changed by the HCL2 formatting engine. The
check flag is mutually exclusive with the write flag and will only check
if formatting is needed.
The update write flag will now overwrite the source files with the newly
formatted HCL2 source unless the `-write=false` or `-check` is passed at
the command line.
* Returns a diagnostic error if Format is unable to show a diff - equivalent to `terraform fmt`
* Updates testing to run against #Format and not the private methods of the HCL2Formatter; fixes ShowDiff test failure on Windows
* Updates comments for exported functions
* Add docs for fmt command
* handle template_dir, pwd funcs, handle min_packer_version
* gotpl packer_version becomes hcl2 packer.version
* uuid becomes hcl2 uuidv4
* test code with emojis
* handle all cases were we cannot guess what the argument was
* handle clean_resource_name cases
* up docs
* add the possibility to set the packer.required_version field; to make sure the template file works with that version of Packer
* add tests
* add documentation on packer.required_version
Example:
packer {
required_version = ">= 1.2.0, < 2.0.0"
}
Before change
```
Usage: packer [--version] [--help] <command> [<args>]
Available commands are:
build build image(s) from template
console creates a console for testing variable interpolation
fix fixes templates from old versions of packer
hcl2_upgrade build image(s) from template
inspect see components of a template
validate check that a template is valid
version Prints the Packer version
```
After change
```
Usage: packer [--version] [--help] <command> [<args>]
Available commands are:
build build image(s) from template
console creates a console for testing variable interpolation
fix fixes templates from old versions of packer
hcl2_upgrade transform a JSON template into a HCL2 configuration
inspect see components of a template
validate check that a template is valid
version Prints the Packer version
```
when it encounters map[string]interface{} or []interface{} types, hcl2_upgrade now takes the 'most complex' entry from those in order to tell wether this is going to be a body `body {}` or an attribute `attribute = {}`. Before that the hcl2_upgrade command could be a bit random there.
A way better ( but may be somewhat hard ) way to do this would be to use the actual plugins structs in order to generate the HCL2.
hcl2_upgrade transforms a JSON build-file in a HCL2 build-file.
This starts a validated Packer core and from that core we generate an HCL 'block' per plugin/configuration. So for a builder, a provisioner, a post-processor or a variable. The contents of each block is just transformed as is and basically all fields are HCL2-ified.
A generated field can be valid in JSON but invalid on HCL2; for example JSON templating (in mapstructure) allows to set arrays of strings - like `x = ["a", "b"]` - with single strings - like `x="a"` -, HCL does not allow this.
Since JSON does not make the distinction between variables and locals, everything will be a variable. So variables that use other variables will not work.
hcl2_upgrade tries to transform go templating interpolation calls to HCL2 calls when possible, leaving the go templating calls like they are in case it cannot.
Work:
* transpiler
* tests
* update hcl v2 library so that output looks great.
* update docs
added `post-processors` block to run chained post-processors after a build.
Before this, defining multiple `post-processor` blocks after
provisioning steps would run them sequentially, now doing this makes them start
from the build's artifact. To queue post-processors you now have to define them
in a `post-processors` block.
This is a breaking change.
The initialization of packer core in JSON also validates that `null` variables were set, except in the case of `packer validate --syntax-only` , but after the refactor to allow to have all commands work with HCL2 and JSON this subtlety was lost.
This refactors the initialisation of the core in order to allow to have `packer validate --syntax-only` not error in case a variable is not set. Since these calls are refactored this works for HCL2 too.
fix#9478
