13 Commits (26af7901fec0cf71e0513fb243191baf8a2d7008)

Author	SHA1	Message	Date
hashicorp-copywrite[bot]	b7df3ca36f	[COMPLIANCE] Add Copyright and License Headers (#12254) ... Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>	3 years ago
Wilken Rivera	d880d1bca7	Update ReadFromHCLBuildBlock to use the hcp_packer_registry.Description ... In packer v1.8.5, the bucket's description was not properly set in the bucket object we use for HCP, therefore all the buckets created by Packer did not have their description updated. Before the change ``` --- FAIL: TestReadFromHCLBuildBlock (0.00s) --- FAIL: TestReadFromHCLBuildBlock/configure_bucket_using_only_hcp_packer_registry_block (0.00s) types.bucket_test.go:380: expected the build to to have contents of hcp_packer_registry block but it does not: &registry.Bucket{ Slug: "hcp_packer_registry-block-test", - Description: "", + Description: "description from hcp_packer_registry block", Destination: "", BucketLabels: {"org": "test"}, ... // 5 identical fields } FAIL FAIL github.com/hashicorp/packer/internal/hcp/registry 1.072s FAIL ``` After Change ``` ~> go test ./... ? github.com/hashicorp/packer/internal/hcp/api [no test files] ok github.com/hashicorp/packer/internal/hcp/env (cached) ok github.com/hashicorp/packer/internal/hcp/registry 1.130s ```	3 years ago
Lucas Bajolet	ec1d2e68f5	hcp: generate fingerprints on each new build ... Fingerprints are how we link a packer build to an iteration on HCP. These are computed automatically from the Git SHA in the current state, and are unique to the bucket/iteration. The main problem with this approach is that while sound in theory, it quickly falls apart when users want to run the same build configuration twice, but expect a new image to be created. With the current model, this fails, as the iteration with the current SHA already exists. While this is solvable through environment variables, or by committing a change to the repository, we think this is not clear enough, and causes an extra step to what should otherwise be a simple process. Therefore, to lower the barrier of entry into HCP, we change this behaviour with this commit. Now, fingerprints are randomly generated ULIDs instead of a git SHA, and a new one is always generated, unless one is already specified in the environment. This makes continuation of an existing iteration a conscious choice rather than something automatic, and virtually eliminates conflicts such as the ones described above.	3 years ago
Lucas Bajolet	73482bb636	internal: remove unused Labels on Iteration ... The iteration structure that we use for linking a packer build to an iteration on HCP defines a `Labels' attribute, which is never set nor read from at any point. Since it is unused, we remove it in this commit.	3 years ago
Lucas Bajolet	ca197afe9b	hcp: remove superfluous return value on GetBuilds ... This commit irons out one of the pain points of the HCP rework by introducing a HCPPublisher interface, implemented both by the JSON Core, and the HCL2 PackerConfig, which keeps a map of the build names used by Packer to the build names pushed on HCP. This in turn lets us go back to the old implementation of the GetBuilds function, which returns a list of (filtered) builds, and eventually an error if something went wrong while processing.	3 years ago
Lucas Bajolet	2200cb14ce	hcp: set the status to CANCELLED when a build is ... Related to the previous behaviour problem, this changes how the status of a build is set on HCP Packer, as a cancelled build is different from a failed one, we can set it to the appropriate state on cancellation.	3 years ago
Lucas Bajolet	4846301ff4	hcp: reject template type changes between builds ... As a follow-up to tracking the template type for an iteration, we actively check that it remains consistent between two invocations of packer, and reject the update if it is not the case.	3 years ago
Lucas Bajolet	6d0045607c	hcp: record template type when creating iterations ... In order to ensure users keep the same templates between two packer invocations for a single iteration, we start tracking the type of template used when building images.	3 years ago
Lucas Bajolet	08f1e85fb1	hcp: fix payloads for new SDK version ... The grpc_gateway v2 changes had some repercussions in the payloads of the API calls, making the current code non-functional against the latest SDK.	3 years ago
Lucas Bajolet	ccb5a22bb4	hcp: remove duplicated build registration for JSON ... In JSON templates, we register the builds to process on HCP at the initialisation of the Registry. However, during the HCP breakout, this code was duplicated with a slight difference for the JSON templates, and the build names were registered once during initialisation, with the expected full name, and once at the start of PopulateIteration, with the truncated name. This caused a bug when processing a template that contains a builder with both a name and a type, as both would be registered, but only one would complete, leading to the iteration being unable to complete.	3 years ago
Lucas Bajolet	719c8681cd	registry: don't use datasource output for ancestry ... The ancestry inferral code relied on HCP datasource outputs for deciding what would be the ancestry for an image built with HCP. This brings a dependency into the hcp package, which is not really necessary as we only need a few information from those entities, hence this commit removes the full dependency on the structures, in favour of more focused data structures where we only cherry pick what is necessary for this code.	3 years ago
Wilken Rivera	606e6c48f1	internal: reorganise registry/HCP code ... 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.	3 years ago
Lucas Bajolet	1cee460d0d	hcp: extract all HCP-related code to hcp package ... As part of the work to displace everything related to HCP from scattered places around the Packer code, we move it all to an hcp package. This in turn reduces the amount of code that the commands have to integrate, and leaves the HCP details to its own enclave.	3 years ago