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

  1. Verify the build/component name matches one created during this run
  2. Run one Packer invocation per bucket/version to keep registry state coherent
  3. Check that labels are being published to the correct bucket and fingerprint
  4. 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

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


AI-assisted analysis of hashicorp/packer@eb36e3c3e4 (2026-09-05). Data as JSON: /api/errors/826ad90f9a726e4f. Report an issue: GitHub.