If you’re already using CUE to validate or generate Kubernetes manifests then you probably used the cue get go command to create the relevant packages and schemas:

$ cue get go k8s.io/api/apps/v1

This command generates and stores CUE schemas under cue.mod/gen/k8s.io/ after you’ve also fetched the relevant Go source code.

The CUE Central Registry provides a well-known location for well-known modules and schemas, including those from the Kubernetes project. You can easily modify your CUE to rely on up-to-date, curated schemas published on the Central Registry by using the cue refactor imports command. This guide shows you how.

The latest pre-release of the cue command is required – please upgrade to this version if it’s not already installed:

$ cue version
cue version v0.13.0-alpha.3
...

Check your current CUE

Having schemas generated by cue get go has allowed you to validate Kubernetes manifests, or to generate them from CUE code like this:

// filepath: manifest.cue

package kube

import apps "k8s.io/api/apps/v1"

apps.#Deployment & {
	apiVersion: "apps/v1"
	kind:       "Deployment"
	metadata: {
		labels: app: "example1"
		name: "example1"
	}
	spec: {
		replicas: 1
		selector: matchLabels: app: "example1"
		template: {
			metadata: labels: app: "example1"
			spec: containers: [{
				image: "nginx:latest"
				name:  "nginx"
			}]
		}
	}
}

The import line, at the top of this CUE file, specifies the location of the schemas previously generated from the Kubernetes source code. These schemas allow the cue vet command to catch validation problems in our manifest:

$ cue vet -c

Because cue vet doesn’t print any errors, we know that the manifest currently validates successfully.

Login to the Central Registry

$ cue login # only during beta

The Central Registry requires authentication while it’s in beta testing, so you need to login before you can fetch the curated Kubernetes module.

Update your CUE files

To update the relevant imports across every CUE file in your module, run the cue refactor imports command with a “before” and “after” prefix. In the case of Kubernetes schemas, this is the command you need to run:

$ cue refactor imports k8s.io test.cue.works/x1/k8s.io

CUE files are re-written, updating import lines as required:

// filepath: manifest.cue

package kube

import apps "test.cue.works/x1/k8s.io/api/apps/v1"

apps.#Deployment & {
	apiVersion: "apps/v1"
	kind:       "Deployment"
	metadata: {
		labels: app: "example1"
		name: "example1"
	}
	spec: {
		replicas: 1
		selector: matchLabels: app: "example1"
		template: {
			metadata: labels: app: "example1"
			spec: containers: [{
				image: "nginx:latest"
				name:  "nginx"
			}]
		}
	}
}

The import line at the top now references the appropriate curated module for the deployment contained in the manifest. Its path is currently temporary, but only while its proper location is being decided. The temporary path isn’t a problem because one important property of the Central Registry is that, once a schema is published, it will always be available at that location. When the curated module’s location is finalised and versions are published under the new path, you can easily use the cue refactor imports command to update your CUE again!

Tidy your CUE module

$ cue mod tidy

Tidying your CUE module fetches the Kubernetes module from the Central Registry, and updates the cue.mod/module.cue file to track this dependency:

$ cat cue.mod/module.cue
module: "kube.example"
language: {
	version: "v0.13.0"
}
deps: {
	"test.cue.works/x1/k8s.io@v0": {
		v: "v0.3.0"
	}
}

Updating to a later version of a curated module is performed by a different command (not cue refactor imports) – we’ll be publishing a guide about how to do that, soon!

Remove the old packages and schemas

The schemas stored in the cue.mod/gen/k8s.io/ directory are no longer needed, and should be deleted:

$ rm -r cue.mod/gen/k8s.io/

Check your updated CUE

$ cue vet -c

Because cue vet doesn’t print any errors, we know that the manifest still validates successfully against the new schemas.