Since the protos for uploading an SBOM for a build have been changed to
use an enumeration instead of a plain string with the latest revisions
to the HCP Packer SBOM support feature, we update how we reference those
values for the SBOM format to use that enum instead.
When a build cannot be completed without errors, the build state was
left as running, unless the build explicitly failed, which meant that
HCP Packer would be responsible for changing the status after the
heartbeats for the build stopped being sent for two 5m periods.
This commit changes this behaviour, by explicitly marking the build as
failed if something did not work while trying to complete a build on HCP
Packer, even if the local Packer core build succeeded before that.
Since packer now supports keeping track of SBOMs produced during a
build, we add the code to integrate those changes into the internal/hcp
package, so we do upload them on build completion.
In HCP's metadata package, especially the VCS/git parts, we keep the
current HEAD for a repository, along with the state it is in, in order
to report it to HCP Packer when the build completes.
However, when a build is run on a template from an empty Git repository,
and HCP Packer is enabled, the code would crash when trying to get the
information on the current HEAD, as it doesn't exist.
The git library we use returns an error in such a case, but this was
ignored, leading to a crash when attempting to get the hash to this
reference later on.
This commit fixes the problem by NOT ignoring the error to get the head,
and immediately stop processing the git data as it doesn't yet exist.
* Update UpsertBucket to first call GetBucket, this will allow bucket level role based authentication, as CreateBucket uses project level auth
* Fix one incorrect test failure message
With Packer 1.10.1 we started warning when a build failed to complete
because of a potential incompatibility with the builder being used.
This led to cases in which the build failed for other reasons, and
Packer would still warn of potential incompatibilities, even if the
builder was in effect HCP compatible.
We attempted to fix this issue by introducing a new error type, and
checks when we read the artifacts linked to a build, however this loop
would fail when any one of the artifacts is not compatible with HCP
Packer, leading to false failures.
To avoid this problem, we log incompatibilities to the verbose logger,
and only signal the problem if all the artifacts could not be used to
upload data to HCP Packer, in which case it's almost certain that if the
build succeeded and no artifacts are registered to the build, that all
the components used are not compatible with HCP, and should be reported
as such to users.
When running a build with HCP Packer enabled, Packer attempts to push
the build status to HCP.
If the build fails, we update the status to BUILD_FAILED, and that's the
end of it.
If however the build succeeds, Packer attempts to get the HCP artifact
from the builder, which will only succeed if the builder supports it.
Otherwise, we'll get either nil, or an artifact type that is not
compatible with what is expected for HCP support.
When either of those happens, we warn that the builder may not support
HCP Packer at all, so users are aware of the problem.
However, when the error was introduced, it only looked at the fact that
an error was produced, independently of the type of error. This caused
legitimate errors while building to be reported as potential
incompatibility between the builder and HCP, which was confusing to
users.
This commit changes this by introducing a new error type, only produced
when the artifact either is nil, or failed to be deserialised into a HCP
artifact, which lets us produce the incompatibility warning with more
accuracy.
* 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>
When setting a project id via the HCP_PROJECT_ID env the client will try to validate the project
by checking that it has an associated registry. If the project is invalid or not a valid UUID an error
will be displayed to the user
* Add comment to clarify usage of SDK loaded env. variables
HCP supports two types of service principals: Organization-level and project-level.
When a user tries to publish to an active HCP Packer registry using a plsp the client
fails when configuring the client due to a API permission error; namely plsp do not have
the permissions to query an org for a list of projects. Setting the HCP_PROJECT_ID does
not resolve the issue because the call to ListProjects is still executed.
This changes updates the client configuration params to obtain both the HCP Organization and
Project IDs that will be used for connecting to the HCP Packer registry. With this change
if a user provides a project Id via the HCP_PROJECT_ID environment variable no call to ListProjects will
be made. Instead the value will be take as is and used to create the connection. A user connecting with
a project level service principals must provide a valid HCP_PROJECT_ID in order to connect.
With HCP supporting multi-projects now, Packer needs to take it into
account when picking a project from an organisation.
This commit adds two cases:
1. multiple projects are defined, none is supplied through
HCP_PROJECT_ID: in this case we will default to the oldest project
defined for the organisation.
2. we supply HCP_PROJECT_ID: in this case, we pick the project with the
corresponding ID, and use it for publishing metadata.
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: ®istry.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
```
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.
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.
Jenna Goldstrich
Lucas Bajolet
Devashish
Wilken RiveraandLucas Bajolet
hashicorp-copywrite[bot]