Using cue as container

[roylisto]

Hi I've seen cue has this dockerfile
https://github.com/cue-lang/cue/blob/master/Dockerfile
I want to know what purpose of this file? does it mean we can run it as a container?
Because I would love to know how to run Cue at Github Action/Gitlab CI Pipeline

Thank you

[verdverm]

https://hub.docker.com/r/cuelang/cue

These are created by Goreleaser, see the .goreleaser.yml

[roylisto]

Ah okay, thanks

[myitcv]

@roylisto to run CUE as part of your CI pipeline, you could use something like https://github.com/moia-oss/setup-cue or simply go install cuelang.org/go/cmd/cue@latest.

Alternatively, you can use a Docker image that has CUE available; the Docker file you link is a bare-bones image that, as @verdverm says, is built by this project at release time.

[roylisto]

alright thank you , will take a look

[roylisto]

Hi @myitcv So I can't use sh at the container? I got this error when running the docker image at Gitlab pipeline
container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown (exec.go:57:0s)

Do you think we can wrap the cue inside the alpine image?

[verdverm]

The base image is from this repo: https://github.com/GoogleContainerTools/distroless

They have a discussion as to why distroless is better. I see a lot of FROM scratch as well. I personally use more comprehensive images in my CI pipelines because I often employ scripts and Make so I can have parity between local dev and CI.

Not that this answers your question. Perhaps CUE could create more images rather than changing the existing one? That begs the question of which, as there are many possibilities and it is not overly difficult to add cue to an existing image.

[myitcv]

Do you think we can wrap the cue inside the alpine image?

Previous discussion in #968. If we can establish some grounds for having multiple Docker images (e.g. "having an Alpine image helps enable X, Y and Z, something that we can't do ourselves because of A, B and C"), then we could consider adding more targets to the release pipeline, but that will need to be weighed up against the increased complexity/maintenance surface.

[jpluscplusm]

For me, the most significant advantage of having a shell inside the/a "blessed" CUE container is to allow file globbing.

Whilst the CUE package/module/etc management is evolving, and I'm in the earlier stages of introducing CUE to folks&project I work with, there are still many places where a blanket cue <command> <package> isn't viable. In these places, cue <command> <file-list> is essential, and right now I can't use the official container in a generalised way, across CI/CD pipelines, as <file-list> might vary by project.

The list injected into the official container image's command needs to be concrete, as the list doesn't go through any file globbing.

Adding a shell would allow me to enter the container via that shell, get the shell to do whatever globbing is needed, and drive cue in the explicit-file-list way that's needed before one has adopted and fully rounded out "how we do CUE packages at company "! :-)