GoogleContainerTools/skaffold · error
unexpected artifact type %q: %s
Error message
unexpected artifact type %q: %s
What it means
sourceDependenciesForArtifact switches over the artifact type (docker, kaniko, bazel, jib, buildpacks, ko). If none matches — the artifact has no recognized type set, or a type Skaffold's dependency resolution doesn't support — it throws this error including the artifact type string and a formatted dump of the artifact.
Source
Thrown at pkg/skaffold/graph/dependencies.go:162
paths, err = docker.GetDependencies(ctx, docker.NewBuildConfig(kaniko.GetContext(a.KanikoArtifact, a.Workspace), a.ImageName, a.KanikoArtifact.DockerfilePath, args), cfg)
case a.BazelArtifact != nil:
paths, err = bazel.GetDependencies(ctx, a.Workspace, a.BazelArtifact)
case a.JibArtifact != nil:
paths, err = jib.GetDependencies(ctx, a.Workspace, a.JibArtifact)
case a.CustomArtifact != nil:
paths, err = custom.GetDependencies(ctx, a.Workspace, a.ImageName, a.CustomArtifact, cfg)
case a.BuildpackArtifact != nil:
paths, err = buildpacks.GetDependencies(ctx, a.Workspace, a.BuildpackArtifact)
case a.KoArtifact != nil:
paths, err = ko.GetDependencies(ctx, a.Workspace, a.KoArtifact)
default:
return nil, fmt.Errorf("unexpected artifact type %q:\n%s", misc.ArtifactType(a), misc.FormatArtifact(a))
}
if err != nil {
return nil, err
}
return util.AbsolutePaths(a.Workspace, paths), nil
}
View on GitHub (pinned to a1189de023)
Solutions
- Check skaffold.yaml for an artifact entry missing its build type definition (empty or malformed build stanza).
- If using a custom builder, note that source-dependency computation doesn't support it — define watch/file dependencies explicitly or switch to a supported builder.
- When calling the resolver programmatically, populate one of the typed artifact fields (e.g. DockerArtifact) before invoking.
- Read the %q artifact type and format dump in the message to identify which artifact was untyped.
Defensive patterns
Strategy: type-guard
Type guard
func hasSupportedArtifactType(a *latest.Artifact) bool {
return a != nil && (a.DockerArtifact != nil || a.KanikoArtifact != nil ||
a.BazelArtifact != nil || a.JibArtifact != nil ||
a.BuildpackArtifact != nil || a.KoArtifact != nil)
} Prevention
- Ensure every skaffold.yaml artifact has exactly one build type stanza
- Don't feed custom/custom-tool artifacts into source-dependency resolution
- Validate skaffold.yaml with `skaffold diagnose` before running pipelines
- When constructing Artifacts programmatically, set one typed field explicitly
When it happens
Trigger: An Artifact struct reaches sourceDependenciesForArtifact with all of DockerArtifact/KanikoArtifact/BazelArtifact/JibArtifact/BuildpackArtifact/KoArtifact nil — e.g. a custom resolver handing over an untyped artifact, a custom builder plugin artifact, or an artifact constructed programmatically without setting its type.
Common situations: Using custom build types (e.g. `customArtifact` or cluster-only artifacts) in a context that computes source dependencies; programmatic use of the resolver API with hand-built Artifact structs; skaffold.yaml parsing produced an empty artifact definition.
Related errors
- image %q context %q is not a directory
- creating tagger: %w
- creating tester: %w
- bucket name is empty
- INSPECT_PROFILE_NOT_FOUND_ERR
AI-assisted analysis of GoogleContainerTools/skaffold@a1189de023 (2026-09-05).
Data as JSON: /api/errors/739c2d5d296ec6c7.
Report an issue: GitHub.