hashicorp/packer · error
AddLabelsToBuild: %w
Error message
AddLabelsToBuild: %w
What it means
Wraps a failure from Version.Build while resolving the named build, inside AddLabelsToBuild. It means labels could not be attached because no build with that name exists in the version (or the stored entry is not a valid Build).
Source
Thrown at internal/hcp/registry/types.version.go:115
build, err := version.Build(buildName)
if err != nil {
return fmt.Errorf("AddArtifactToBuild: %w", err)
}
err = build.AddArtifacts(artifacts...)
if err != nil {
return fmt.Errorf("AddArtifactToBuild: %w", err)
}
version.StoreBuild(buildName, build)
return nil
}
// AddLabelsToBuild merges the contents of data to the labels associated with the build referred to by buildName.
func (version *Version) AddLabelsToBuild(buildName string, data map[string]string) error {
build, err := version.Build(buildName)
if err != nil {
return fmt.Errorf("AddLabelsToBuild: %w", err)
}
build.MergeLabels(data)
version.StoreBuild(buildName, build)
return nil
}
// AddSHAToBuildLabels adds the Git SHA for the current version (if set) as a label for all the builds of the version
func (version *Version) AddSHAToBuildLabels(sha string) {
version.builds.Range(func(_, v any) bool {
b, ok := v.(*Build)
if !ok {
return true
}
b.MergeLabels(map[string]string{
"git_sha": sha,View on GitHub (pinned to eb36e3c3e4)
Solutions
- Verify the build/component name matches one created during this run
- Run one Packer invocation per bucket/version to keep registry state coherent
- Check that labels are being published to the correct bucket and fingerprint
- Inspect the wrapped error to distinguish 'no associated build found' from an invalid Build type
Defensive patterns
Strategy: type-guard
Validate before calling
// Ensure the build exists before merging labels
if !version.HasBuild(buildName) {
return fmt.Errorf("cannot add labels: build %q not found on version", buildName)
} Type guard
if _, err := version.Build(name); err != nil {
return fmt.Errorf("labels target build %q unavailable: %w", name, err)
} Try / catch
if err := version.AddLabelsToBuild(name, labels); err != nil {
if strings.Contains(err.Error(), "no associated build found") {
// create the build first, then re-apply labels
}
} Prevention
- Apply labels only to builds created within the same run
- Verify component names against the template's builder names
- Avoid sharing one bucket across concurrent Packer invocations
When it happens
Trigger: AddLabelsToBuild is called (via UpdateLabelsForBuild) with a buildName absent from version.builds — e.g. label updates arriving for a component this Packer run never created a build for.
Common situations: Same split-brain scenario as AddArtifactToBuild: parallel builds sharing a bucket, component name mismatches, or label updates landing after the version instance was replaced.
Related errors
- failed to get build %q from version being built. This is a P
- AddArtifactToBuild: %w
- error retrieving version from HCP Packer Registry: %s
- error retrieving channel from HCP Packer Registry: %s
- there is no version associated with the channel %s
AI-assisted analysis of hashicorp/packer@eb36e3c3e4 (2026-09-05).
Data as JSON: /api/errors/826ad90f9a726e4f.
Report an issue: GitHub.