GoogleContainerTools/skaffold · error

unable to create build args: %w

Error message

unable to create build args: %w

What it means

sourceDependenciesForArtifact starts by computing Docker env tags via docker.EnvTags(tag); if that fails it wraps the error as 'unable to create build args'. Note a quirk: it wraps `err`, not `evalErr`, so the underlying cause is masked by whatever `err` happened to hold (usually nil). The failure means the tag string could not be parsed into environment-variable build-arg pairs.

Source

Thrown at pkg/skaffold/graph/dependencies.go:121

	deps := make([]string, len(res))
	copy(deps, res)
	return deps, nil
}

func (r *dependencyResolverImpl) Reset() {
	r.cache = util.NewSyncStore[[]string]()
}

// sourceDependenciesForArtifact returns the build dependencies for the current artifact.
func sourceDependenciesForArtifact(ctx context.Context, a *latest.Artifact, cfg docker.Config, r docker.ArtifactResolver, tag string) ([]string, error) {
	var (
		paths []string
		err   error
	)

	envTags, evalErr := docker.EnvTags(tag)
	if evalErr != nil {
		return nil, fmt.Errorf("unable to create build args: %w", err)
	}

	switch {
	case a.DockerArtifact != nil:
		// Required artifacts cannot be resolved when `ResolveDependencyImages` runs prior to a completed build sequence (like `skaffold build` or the first iteration of `skaffold dev`).
		// However it only affects the behavior for Dockerfiles with ONBUILD instructions, and there's no functional change even for those scenarios.
		// For single build scenarios like `build` and `run`, it is called for the cache hash calculations which are already handled in `artifactHasher`.
		// For `dev` it will succeed on the first dev loop and list any additional dependencies found from the base artifact's ONBUILD instructions as a file added instead of modified (see `filemon.Events`)
		deps := docker.ResolveDependencyImages(a.Dependencies, r, false)

		args, evalErr := docker.EvalBuildArgsWithEnv(cfg.Mode(), a.Workspace, a.DockerArtifact.DockerfilePath, a.DockerArtifact.BuildArgs, deps, envTags)
		if evalErr != nil {
			return nil, fmt.Errorf("unable to evaluate build args: %w", evalErr)
		}
		paths, err = docker.GetDependencies(ctx, docker.NewBuildConfig(a.Workspace, a.ImageName, a.DockerArtifact.DockerfilePath, args), cfg)

	case a.KanikoArtifact != nil:
		deps := docker.ResolveDependencyImages(a.Dependencies, r, false)

View on GitHub (pinned to a1189de023)

Solutions

  1. Check the resolved tag value — run `skaffold build --tag` or inspect the tagger config for characters that break parsing.
  2. Fix the tagger configuration (envTemplate/custom tags) so it emits a valid Docker tag.
  3. Confirm the upstream artifact resolved a non-empty tag (fix 'unable to resolve tag for image' first if present).
  4. Note the wrapped `err` may be nil due to a wrapping bug — enable debug logging (`-vdebug`) to see the original EnvTags failure.

Example fix

// before (envTemplate tagger with unresolved variable)
 tagName: '{{.MISSING_VAR}}'
// after
 tagName: '{{.IMAGE_NAME}}-{{.DIGEST}}'
Defensive patterns

Strategy: validation

Validate before calling

// Validate the resolved tag looks like a Docker tag before dependency resolution
if tag == "" || strings.ContainsAny(tag, " \t\n") {
	return fmt.Errorf("invalid image tag %q before build-args creation", tag)
}

Prevention

When it happens

Trigger: Any artifact (docker, kaniko, buildpacks, ko, etc.) going through sourceDependenciesForArtifact when docker.EnvTags(tag) fails — i.e. the resolved image tag contains characters that break tag parsing, or the tag is empty/malformed.

Common situations: Image tags produced by custom taggers containing unusual characters or template remnants; an empty tag because upstream resolution failed (see 'unable to resolve tag for image'); misconfigured custom tagger output.

Related errors


AI-assisted analysis of GoogleContainerTools/skaffold@a1189de023 (2026-09-05). Data as JSON: /api/errors/93cc2fdb2b33e8a2. Report an issue: GitHub.