#Converting Cue Plans to Go SDK

1 messages · Page 1 of 1 (latest)

languid shuttle
#

" I started looking at converting my existing cue plan to the go sdk (which looks great so far!), but I don't think there are enough examples in the current docs to help wrap my head around what "design patterns" i should be using to mimic what I'm doing now, if that makes sense. I sorta don't know exactly where to start

for example the declarative cue plan has high level concepts like the "client" and "actions", how should I structure my dagger code to match these patterns? "

#

@ember talon was the requestor of the question above. We moved from DM to help forum.

trim gust
#

Yeah at the very least we should write a quick guide picking some low hanging fruits, for example "word X means word Y" etc

languid shuttle
#

@strange river one to follow. @pastel portal would love your thoughts here on how to help @ember talon

#

cc @tough root @grim sleet

trim gust
#

@ember talon just to pick a few things now:

  • The client key is equivalent to the host operations in the new API. You can do all the same stuff,: read / write to/from filesystem etc
#

One difference is that you cannot run commands on the client via the new API. You need to run them yourself with your native stdlib, and pass the result to Dagger as needed

ember talon
#

Here are a few notes I wrote down while learning the new go sdk:

  • Initial docs are good
  • need to make the contents section of the docs page wider
  • It is initially not obvious what this ID refers to. (image1)
  • Based on intellisense alone, this seemed like it should have worked (image2)
  • use of Read() to get a Directory() was not obvious (image3)
  • unsure about when to use <container>.ExitCode()
  • dagger.HostDirectoryWriteOpts should be able to MkdirAll for you
  • unsure how to go about mounting my ~/go/pkg/mod as a cache directory
  • (feature idea) There should be a way to "pause" the running dagger engine and get a shell directly to the running container where you can inspect filesystem contents
  • The code example in WithMountedCache was very helpful, but hard to find - some of the godoc examples should be added to the docs site
image1.png image2.png unknown.png
trim gust
#
  • use of Read() to get a Directory() was not obvious (image3)

We agree and actually changed that in main, waiting for a few more breaking changes before cutting a release, cc @violet delta

ember talon
#

in general the directory types seemed confusing, HostDirectory/Directory/DirectoryID etc

#

i saw some discussion on that in the discord and it looked like that would be potentially changing though

#

also how do I get the fancy moby progressui output back? 😄

languid shuttle
strange river
#

Regarding "The code example in WithMountedCache was very helpful, but hard to find - some of the godoc examples should be added to the docs site" - I agree, i think we should have a space for code samples under each SDK

ember talon
#

additional notes:

  • my build process ends up generating a lot of output (1GB or so), but not all of the generated files need to be copied over to the host at the end of the build. is there a way to copy individual files from a container to the host instead of entire directories? i could not figure out how to do this.
trim gust
gray glacier