Crossplane KCL function allows developers to use KCL (a DSL) to write composite logic without the need for repeated packaging of crossplane functions, and we support package management and the KRM KCL specification, which allows for OCI/Git source and the reuse of KCL's module ecosystem.

# Run code generation - see input/generate.go
$ go generate ./...

# Run tests - see fn_test.go
$ go test ./...

# Build the function's runtime image - see Dockerfile
$ docker build . --tag=kcllang/crossplane-kcl

# Build a function package - see package/crossplane.yaml
$ crossplane xpkg build -f package --embed-runtime-image=kcllang/crossplane-kcl

# Push a function package to the registry
$ crossplane --verbose xpkg push -f package/*.xpkg docker.io/kcllang/crossplane-kcl

See here

cat <<EOF | kubectl apply -f -
apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
  name: kcl-function
spec:
  package: docker.io/kcllang/crossplane-kcl
EOF

Logs are emitted to the Function's pod logs. Look for the Function pod in crossplane-system.

Info   # default
Debug  # run with --debug flag

A KRM YAML list which means that each document must have an apiVersion, kind

Here's what you can do in the KCL script:

• Return an error using assert {condition}, {error_message}.
• Read the ObservedCompositeResource from option("params").oxr.
• Read the ObservedComposedResources from option("params").ocds.
• Read the DesiredCompositeResource from option("params").dxr.
• Read the DesiredComposedResources from option("params").dcds.
• Read the environment variables. e.g. option("PATH") (Not yet implemented).

You can directly use KCL standard libraries such as regex.match, math.log.

• See here to study more features of KCL.