Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: don't suggest lack of HCP support on fail #12835

Merged
merged 1 commit into from
Feb 13, 2024

Conversation

lbajolet-hashicorp
Copy link
Contributor

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.

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.
@lbajolet-hashicorp lbajolet-hashicorp marked this pull request as ready for review February 7, 2024 16:29
@lbajolet-hashicorp lbajolet-hashicorp requested a review from a team as a code owner February 7, 2024 16:29
Copy link
Contributor

@nywilken nywilken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit but otherwise good.

@lbajolet-hashicorp lbajolet-hashicorp merged commit 548893b into main Feb 13, 2024
12 checks passed
@lbajolet-hashicorp lbajolet-hashicorp added the backport/1.10.x Backport PR changes to `release/1.10.x` label Feb 21, 2024
@lbajolet-hashicorp lbajolet-hashicorp deleted the hcp_no_support_error_more_accurate branch February 21, 2024 14:14
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backport/1.10.x Backport PR changes to `release/1.10.x` enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants