CUE doesn't seem to be documented at all here yet?

It's true, I now wonder how you discover this experiment :D

I am really interested in Cuelang as I think it can make complex YAML manifests easier to maintain but I didn't have the time to finish working on it and then got distracted.

It's true, I now wonder how you discover this experiment :D

basically random luck: I have a strange vendetta against templated YAML, and when I found updatecli I was like "huh what are the chances it supports literally anything else", lo and behold...

After experimenting a bit with your pull request, I now remember where I stopped.

I am not a Cuelang expert so maybe you'll have good suggestion.

My first problem was dynamic values, and how to handle them correctly in Cuelang.
It's quite common to use source output in manifest.
In go templates, it looks like

# Make sure that found URLs exist
conditions:
  checkGetLatestLTSLinuxAMD64InstallerURL:
    name: Check if getLatestLTSLinuxAMD64InstallerURL returns an existing URL 
    kind: file
    disablesourceinput: true
    spec:
      files:
        - '{{ source "getLatestLTSLinuxAMD64InstallerURL" }}' 

Where source is a custom Updatecli function.

The value of '{{ source "getLatestLTSLinuxAMD64InstallerURL" }}' is defined by the source configurated with the id "getLatestLTSLinuxAMD64InstallerURL"

That's an information, we only know a runtime.

That's why I was converting cuelang to yaml.
So that the following snippet could work:

sources: {
  default: {
    name: "Get latest Jenkins version"
    kind: "jenkins"
  }

  echo: {
    name: "Echo latest Jenkins version"
    kind: "shell"
    dependson: [
      "default",
    ]   
    spec: {
      command: #"echo {{ source "default" }}"#
    }   
  }

Unfortunately, I wasn't a big fan of this solution, as we now need to understand Cuelang, Updatecli. and Go templating to write a manifest...

The second limitation I faced was about using standard Cuelang libraries for example to get a value from environment variable which is a very common practice to get credentials from CI pipelines.

The final question I had was how to handle this files in an OCI registry.

Today we can publish any Updatecli manifests to an OCI registry. The way we do that is by having a specific artifact type for values files and another one for configuration files.
But If we decide to also support Cuelang module, then my understanding is that we also need to publish the cue.mod filet
I know many project just create a tgz with all the files, which could be an option

Unfortunately, I wasn't a big fan of this solution, as we now need to understand Cuelang, Updatecli. and Go templating to write a manifest...

Ah yeah, tbh as-is this doesn't bother me too much since the only Go templating you really need to know is {{ source "name" }}. That being said, it's technically possible in CUE to get something similar, like:

sources: {
  default: Source & {
    name: "Get latest Jenkins version"
    kind: "jenkins"
  }

  echo: {
    name: "Echo latest Jenkins version"
    kind: "shell"
    dependson: [
      "default",
    ]   
    spec: {
      command: "\(sources.default.output)"
    }   
  }

You can see examples of it in CUE's tasks support or KubeVela's workflows. It's a bit tricky to implement though, because you need to partially evaluate things to get the initial sources and then re-evaluate it with those filled in.

The second limitation I faced was about using standard Cuelang libraries for example to get a value from environment variable which is a very common practice to get credentials from CI pipelines.

I think you can do something similar here, but I'm not super sure.

Today we can publish any Updatecli manifests to an OCI registry. The way we do that is by having a specific artifact type for values files and another one for configuration files.
But If we decide to also support Cuelang module, then my understanding is that we also need to publish the cue.mod filet

I...am not sure, I haven't looked into this before! I'd imagine Timoni has this sorted out though, because it lets you publish OCI images containing CUE inside.

I think we still have many open questions, but since it's an experimental feature, I am happy to merge it as is and to iterate on this
I am curious about your feedback