GoogleContainerTools/jib · error · UnsupportedOperationException

Only FileLayers are supported at this time.

Error message

Only FileLayers are supported at this time.

What it means

Jib CLI's buildfile parser only supports layers of type FileLayer. When a `layers:` list in the buildfile YAML contains an entry of another layer type (no corresponding FileLayer builder applies), toLayers throws this UnsupportedOperationException. The TODO comment shows empty/other layer kinds are simply not implemented yet.

Source

Thrown at jib-cli/src/main/java/com/google/cloud/tools/jib/cli/buildfile/Layers.java:179

                    addedDirectories.add(parent);
                    if (parent.equals(src)) {
                      break;
                    }
                    parent = Verify.verifyNotNull(parent.getParent());
                  }
                  layerBuiler.addEntry(
                      newEntry.apply(path, filePropertiesStack.getFilePermissions()));
                }
              }
            }
          }
          copySpec.getProperties().ifPresent(ignored -> filePropertiesStack.pop());
        }
        fileLayer.getProperties().ifPresent(ignored -> filePropertiesStack.pop());
        // TODO: add logging/handling for empty layers
        layers.add(layerBuiler.build());
      } else {
        throw new UnsupportedOperationException("Only FileLayers are supported at this time.");
      }
    }
    layersSpec.getProperties().ifPresent(ignored -> filePropertiesStack.pop());
    return layers;
  }

  @VisibleForTesting
  static PathMatcher toPathMatcher(String glob) {
    return FileSystems.getDefault()
        .getPathMatcher(
            "glob:" + ((glob.endsWith("/") || glob.endsWith("\\")) ? glob + "**" : glob));
  }
}

View on GitHub (pinned to fb949e2676)

Solutions

1. Change the layer entry in the buildfile so it is a standard FileLayer (type with files/properties entries)
2. Check the Jib CLI version's supported buildfile schema and remove unsupported layer types
3. Upgrade Jib CLI to a version that may support more layer kinds

Example fix

// before (buildfile)
layers:
  - name: 'other-layer'
    type: 'CustomLayer'
// after
layers:
  - name: 'files'
    files:
      - source: ./app
        destination: /app

for (var layer : layersSpec.getLayers()) { if (!(layer instanceof FileLayer)) throw new IllegalArgumentException("Unsupported layer type: " + layer.getClass().getSimpleName()); }

boolean isFileLayer(Object l) { return l instanceof FileLayer; }

try { layers = toLayers(layersSpec); } catch (UnsupportedOperationException e) { log.error("Unsupported layer type in buildfile: {}", e.getMessage()); }

When it happens

Trigger: Calling toLayers on a LayersSpec whose entries contain a layer that is not a FileLayer — e.g. a layer entry in the buildfile YAML with a different/unrecognized type name, so the instanceof/branch for FileLayer falls through to the else clause.

Common situations: Hand-writing a jib.build.yaml buildfile with a layer type copied from docs of a newer version or another tool; typos in the layer type key; using buildfile features not yet supported by the installed Jib CLI version.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• The input JAR (${jarPath}) is compiled with Java ${jarJavaVe
• Please set the app root of the container with `--app-root` w
• The class file (${jarEntry}) is of an invalid format.
• Reached end of class file (${jarEntry}) before being able to
• Path does not start with forward slash (/): ${unixPath}

AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/712683b08fd40ef0. Report an issue: GitHub.