The acceptance tests for the HTTP datasource had a `Outputs` attribute
for checking the output of the command for a specific regexp pattern.
As pointed out, given the expectative nature of the attribute, naming it
`Outputs` did not make the intent clear, so we rename it to
`ExpectedOutputs` with this commit.
Since the expected error to look for in the output is compiled to a
regexp, the `[]` from the error message were interpreted as a set of
characters, which made the regexp not match the expected output from the
command.
So to avoid this problem, we escape them so they are expected verbatim
in the command output.
Some of the variables we create are flagged by our linters as
ineffective assignments, which makes sense as those are generally fed by
code below, so we don't need to use the declaration/assignation syntax
(:=) but instead can fall back to using var with a type to get the zero
value of the declared entity.
When a server returns a code that is not 200, we error in the current
state.
This is not conformant to the HTTP norm, as anything in the 2xx range is
considered a success, so the datasource should not error in this case.
Therefore, this commit fixes the condition in which we report an error,
so that anything in the 2xx range is now considered a success by the
datasource.
* Updating the license from MPL to Business Source License
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at https://hashi.co/license-faq, and details of the license at www.hashicorp.com/bsl.
* Update copyright file headers to BUSL-1.1
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
The `packer-image-iteration' datasource is an undocumented, and
unexported datasource, so it cannot be used by clients.
Since this is dead weight, we can remove it safely from the codebase.
This commit reorganises the code for both the registry/API and the
Orchestrator/Registry.
The main difference with the previous version is how stuff is exposed.
Now we only expose a Registry interface to the outside (previously named
Orchestrator), which has several implementations: null is the default,
and is returned if HCP is not enabled.
The other implementations being HCL/JSON, both private to the hcp
sub-package.
The api (previously `registry') is the set of functionality that
abstracts and calls the HCP API.
It was meant to be merged with the `hcp' package, but because of a
dependency loop with the datasources, both are separated for now.
* Add `component_type` optional field
to support specifying the exact build image when multiple images exist in the same provider and region for a given iteration
* update docs
* update docs
The comment was mentioning the name of an iteration Id, which is
conflicting.
This commit rephrases the comment to directly specify the ID of the
iteration.
In addition to the current way of specifying an image based on an
iteration on HCP Packer, which requires first declaring an iteration,
and then referencing it from the image to build, we add the capacity of
specifying a channel.
This alternative will get the iteration linked to the channel, and is
essentially a more convenient way to get an image's metadata from HCP
Packer.
This commit is essentially a backport from the Terraform HCP provider,
for consistency between the two tools.
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.
Before change
```
=== Failed
=== FAIL: datasource/hcp-packer-iteration TestAccDatasource_HCPPackerIteration (1.97s)
pluginacc.go:143: Error running plugin acceptance tests: Bad exit code. Logfile: packer_log_hcp_packer_iteration_datasource_basic_test.txt
Logs can be found at /Users/wilkenrivera/Development/packer/datasource/hcp-packer-iteration/packer_log_hcp_packer_iteration_datasource_basic_test.txt
and the acceptance test template can be found at /Users/wilkenrivera/Development/packer/datasource/hcp-packer-iteration/hcp_packer_iteration_datasource_basic_test.pkr.hcl
DONE 690 tests, 5 skipped, 1 failure in 387.912s
```
After change
```
=== SKIP: datasource/hcp-packer-iteration TestAccDatasource_HCPPackerIteration (0.00s)
data_acc_test.go:35: Acceptance tests skipped unless envs "HCP_CLIENT_ID" and "HCP_CLIENT_SECRET" are set
```
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
Lucas Bajolet
Henrik Gerdes
guoguangwu
hashicorp-copywrite[bot]
Wilken Rivera
Shohei Maeda
teddylear
Adrien Delorme
Megan Marsh
