Cue Scripting : Simple Makefile equivalent example?

[cueckoo]

Originally opened by @StevenACoffman in https://github.com/cuelang/cue/issues/428

Is your feature request related to a problem? Please describe. I have used Nix to build docker images but I'm not sure how to use Cue in a similar way. The tutorial shows how to use Cue for Kubernetes, but I'm curious if I can use it for the step before.

Describe the solution you'd like I would like a small example documented.

Describe alternatives you've considered Perhaps Cue's scope is currently too limited to achieve this?

[cueckoo]

Original reply by @verdverm in https://github.com/cuelang/cue/issues/428#issuecomment-645646302

Do you mean build Cue as a binary from source?

What is the step before Kubernetes?

If you are asking if Cue will build docker images, this is possible and something I have done, but requires using the scripting layer. Cue is a language and doesn't really have knowledge about the domain it's being used for, which includes Kubernetes. The docker part of Nix looks to be more of a framework around packaging and environments, which are the kinds of things for packages around Cue rather than Cue itself.

[cueckoo]

Original reply by @StevenACoffman in https://github.com/cuelang/cue/issues/428#issuecomment-645701576

Yes, build a docker image. Sorry for being unclear.

Specifically, an example demonstrating building a docker image using Cue via the scripting layer.

Typically, at my work the desired sequence is:

1. we start from a git repository of source code at a particular git SHA1 commit
2. build docker image from it
3. tag the image with the git SHA1
4. push the image tag to a docker registry (like GCS)
5. update the kubernetes manifests to reference the new image tag (git SHA1)
6. apply the kubernetes manifests

I can perform that same sequence from Bash, Go, Makefile, or Nix scripts. I think it's possible to do this with Cue scripts, but I'm not clear on how and would appreciate an example or guidance on where to look.

[cueckoo]

Original reply by @verdverm in https://github.com/cuelang/cue/issues/428#issuecomment-645842784

Assuming you aren't looking to assemble dockerfiles from more abstract Cue designs, and are mainly looking for more complex examples for the tooling layer, check out https://github.com/hofstadter-io/jumpfiles At this point I'm not really looking to use the scripting layer. I'd rather write Go.

I'm actually working on a new scripting lang & shell. I want the ease of bash for working with arbitrary "stuff," and the abilities we typically have to go to a real language for without needing to.

[cueckoo]

Original reply by @mpvl in https://github.com/cuelang/cue/issues/428#issuecomment-645852400

It should definitely be possible to use CUE for Docker images by using the "exec" task type to shell out to the docker binary.

The disadvantage of using Go is that it is hard to reuse workflows, whereas this is easier with CUE.

[cueckoo]

Original reply by @verdverm in https://github.com/cuelang/cue/issues/428#issuecomment-645858128

Yeah, I already am doing this with other tools as follows:

1. https://github.com/hofstadter-io/jumpfiles/blob/master/lib/devenv_tool.cue
2. https://github.com/hofstadter-io/jumpfiles/blob/master/lib/config.cue#L67
3. https://github.com/hofstadter-io/jumpfiles/blob/master/lib/grid.cue#L66
4. https://github.com/hofstadter-io/jumpfiles/blob/master/lib/k8s/gke.cue

this uses the -t injection to select into a configuration table with defaults around and just shells out to some script that is constructed in pure Cue. The @tag() is awesome, but...

I'm really liking my Cue design, Go runtime experiment because attributes are freaking sweet! There's so much possibility here, how much of that can Cue support natively?

v0.1

• https://github.com/hofstadter-io/hof/blob/master/hof.cue
• https://github.com/hofstadter-io/hof/blob/master/lib/runtime.go#L110

v0.2

• https://github.com/hofstadter-io/hof/blob/master/test.cue
• https://github.com/hofstadter-io/hof/blob/master/lib/test/test.go#L62

TBH though, the experience of writing _tool.cue files is not what I want in a scripting system. For example, being required to write command: name: pkg.Func & { .........} for every thing that can be done in one line today is a step backwards in UX that is tough to accept. (I'm avoiding it for this reason, but I also have a vision for something new brewing, so grain of salt) Another example is testing for a file/dir existence or a ENV val, and then doing something based on that. This is a significant part of scripting and that is highly difficult in Cue, as I understand it should be from Cue's philosophies?