maintainers

[still garnet]

and since replace is ignored by go get, it'd be looking in vendor/ for version A, which isn't what we want

(i'm making a lot of assumptions here)

btw, we potentially need another replace line 😭 https://github.com/dagger/dagger/pull/3560#discussion_r1007077583 cc @wet mason

[wild zephyr]

just checked and indeed vendor contents are not cached by the proxy indeed, so doesn't seem we have an easy way out here

[still garnet]

thanks for checking!

[cosmic cove]

@civic yacht when you have a chance, can you take a look at this PR for improvements to the getting started guide?https://github.com/dagger/dagger/pull/3578

[civic yacht]

Yep will do that today

[wet mason]

@rancid turret should we just go ahead and merge the Python PR as is? We can iterate after that

[rancid turret]

Yep, that's what I said in a comment 🙂

[wet mason]

Let’s do it then 🙂

Not in front of my computer right now

[civic yacht]

Sanity check as I run into more fun with implementing the new multiplatform api approach:

ctr := c.Container().From("alpine").WithPlatform("x86").Exec("uname -a")
outputA, _ := ctr.Stdout().Contents()

ctr = ctr.WithPlatform("aarch64").Exec("uname -a")
outputB, _ := ctr.Stdout().Contents()

fmt.Println(outputA, outputB)

Would you expect the output of the above to be

1. "x86 aarch64"
2. "x86 x86"
   ?
   cc @tepid nova @wet mason @still garnet (but anyone feel free to chime in)

[still garnet]

this feels like a trick question

1 seems obvious from the code, is there some catch?

[civic yacht]

Haha I promise I'm not trying to trick anyone, I agree that 1 seems obvious, I needed to verify my sanity in that regard.

There is a case to be made for 2 in that WithPlatform could be viewed as setting the default for new Directories in the container going forward but not apply to directories that have already been put in the container.

The implication of thinking that 1 is the obvious answer is that it means when you call WithPlatform it "retroactively" applies to Directories that were already loaded into the container. So, you already pulled the alpine rootfs and executed it as x86, but now you want to switch to aarch64.

[still garnet]

ah so will that technically run uname -a twice on the second call?

since it's descending from a x86 uname -a that gets "rebased" to aarch64

[civic yacht]

Exactly, it might be possible to avoid that and only execute the second uname -a but it gets really complicated.

Another cool wrench thrown into all this is that buildkit "bakes" the platform in at llb marshal; when you unmarshal later and try to set a different platform, it does not override anything that was marshalled previously. There's some possible ways of dealing with that though.

[ancient kettle]

Oh... that is weird.

[still garnet]

i think it's kinda weird but I'm not sure how often it'll come up, seems like people would branch off for different architectures rather than replacing them in one pipeline chain with repeated commands

definitely worth documenting though

[civic yacht]

I agree, the problem is that we can't stop them from doing that, just seems like we're planting a bomb

[still garnet]

you could kind of sort of spin it as a feature, since it lets you construct a single pipeline and then run it against multiple architectures, without the pipeline constructor having to know that ahead of time

[ancient kettle]

One of the downsides of the design of Container is somewhat odd/edge-casey behavior like this.

[still garnet]

e.g. goBuildPipeline.WithPlatform("x86").Directory("out").Export(ctx, "out")

[civic yacht]

Yeah that's the primary advantage of allowing WithPlatform to be later in the query rather than the old approach where I put it directly under Query. But it also, like @ancient kettle just said, creates some very surprising cases too

[still garnet]

unrelated: 🧵for go dependency hell

[still garnet]

is this something that could be addressed with a different name? strawman: ForPlatform? it doesn't exactly explain it, but it might make it less surprising that it behaves differently from the other Withs if it has a different name.

[civic yacht]

I was considering ForcePlatform, but also maybe OverridePlatform would be even better

[ancient kettle]

@wet mason @tepid nova @twin crow I ran yarn test from dagger-cue/tests... and I definitely need to make sure this is correct (feels a bit fishy to me currently...) but...

101 tests, 25 failures

[oak sandal]

Is this intended or something that was missed? I just built the binary and the help menu still calls it dagger
https://github.com/dagger/dagger/blob/main/cmd/cloak/main.go#L69

[ancient kettle]

al1000 solomon4104 samalba0001 I ran

What is the expected behavior of

extend type Query {
    "An http remote"
    http(url: String!): File!
}

if the url is not valid? (gives something other than 200 or 2XX)

With core.#HTTPFetch, i get failures if it's an invalid url.

[civic yacht]

I would have expected that to still be the case

[ancient kettle]

I'll double check my implementation.

When I run this with a "bad" url, it doesn't fail:

    fileid, err := dgr.HTTP(httpFetch.Source).ID(ctx)
    if err != nil {
        return nil, err
    }

[civic yacht]

Ah you are running into the emerging common source of confusion; calling .ID doesn't result in execution. It's a special scalar that can be retrieved lazily.

[ancient kettle]

Hmm... the URL is giving a 302

[civic yacht]

Unless there's more code after that

[ancient kettle]

Oh... possibly that, too.

[civic yacht]

One of the reasons to hide ID

[ancient kettle]

I'm also copying that file...

dirId, err := dgr.Directory().WithCopiedFile(httpFetch.Dest, fileid).ID(ctx)

But I suppose it's possible that doesn't execute, either.

[civic yacht]

Yeah, if you try to read the contents you will force an evaluation

[ancient kettle]

I'm getting an empty file, it appears:

    file, err := dgr.File(fileid).Contents(ctx)

    fmt.Println("file:", file)

just prints file:

😕

Seems like this should probably return an error that would get propagated in that case:

https://github.com/dagger/dagger/blob/f1f1b2967eff62346ef7bb34b511a4d641f5e8dc/core/file.go#L115-L118

[still garnet]

are you missing an err check there?

[ancient kettle]

Yes. 😛

Only the File().Contents() call fails, FWIW.

Hmm... Yeah, I'm probably going to need a way to force evaluation.

[rancid turret]

What are your thoughts on a more explicit execution? https://github.com/dagger/dagger/issues/3555

[ancient kettle]

It would be helpful for me with dagger-cue, so I can replicate the previous behavior.

Turns out that simply relying on the convention that something that returns an errors creates an evaluation is incorrect... as seen in the above example.

Which I think is why I was surprised by it.

[rancid turret]

If we resolve the ID specialness does it change your mind? https://github.com/dagger/dagger/issues/3558

[ancient kettle]

Yeah, that would probably resolve it for me.

[civic yacht]

Yeah, was just gonna say that ID is the only exception to that rule (which is why we should hide it). If anything else violates that rule then we need to fix it

[ancient kettle]

I'd personally still like a way to take a Container or Directory and force an evaluation.

[tepid nova]

sync ?

[rancid turret]

With those, you need to select sub fields anyway.

In GraphQL you can't return objects without selecting which fields.

[tepid nova]

would evoke https://man7.org/linux/man-pages/man2/sync.2.html

[civic yacht]

Makes sense, is that because it makes it easier to understand? Or because you want to evaluate something purely for side effects? Both?

[ancient kettle]

Hmm... yeah. If we remove ID, I'm not sure how I can continue my port of dagger-cue (without changing the Europa API).

[tepid nova]

you can still query for ID if needed I guess

[ancient kettle]

I need the side effects to replicate how v0.2 works.

[ancient kettle]

Yeah, that would work.

[civic yacht]

(updating the hide ID issue with this)

[ancient kettle]

Thanks, @civic yacht!

[civic yacht]

https://github.com/dagger/dagger/issues/3558#issuecomment-1294243764

[oak sandal]

Hey folks, just hit a limit (from buildkit API I guess?) . It complained about file size being too large for it to send over.
https://github.com/RealHarshThakur/dagger-builpack/blob/main/main.go#L131

input:1: container.from.withWorkdir.exec.exec.file ResourceExhausted: grpc: received message larger than max (12013895 vs. 4194304)

[oak sandal]

Found an upstream issue related to it. https://github.com/moby/buildkit/issues/2063

[wild zephyr]

Hey folks just hit a limit from buildkit

[ancient kettle]

@still garnet In the comments in https://github.com/dagger/dagger/pull/3560 you said:

Won't help us if/when we need unreleased Buildkit features. There are already some juicy things merged that it'd be nice to use.

I'm curious what you're most excited by.

[still garnet]

the two things I had in mind are importing OCI archives and propagating container hostname as K8S_POD_NAME to CNI plugins (for container-to-container DNS), but I'm sure there are more, it's been a while since they've shipped a minor version

[ancient kettle]

Nice! Yeah, I remember you mentioning those things.

[still garnet]

also support for adding name/other metadata to exported OCI archives

[ancient kettle]

I'm pretty excited about this one... 🙂 https://github.com/moby/buildkit/pull/3228

[still garnet]

lol, yea that too. fortunately that's client-side only so we can just vendor the change if we want to avoid the dependency hell for now

[ancient kettle]

Huh. This could help with forcing evaluations, too: https://github.com/moby/buildkit/pull/3137

[tepid nova]

Trying to stabilize terminology for the internals of the engine, so that we can have more productive conversations about future changes to it ("grenade", etc).

What do you think of this diagram? https://gist.github.com/shykes/5e8ed2d875982aed7a2b41dee3543c2e

[obsidian rover]

Might be a dumb question, but I have a rune in Go, outputed in ascii 50 10 32 32 32 32 32 32 10 32 32 32 32 32 32 32 32 10 32 32 32 32 10 10 32 32 32 32 32 32 32 32 48, I want to Trim all 10 and 32. I tried this func (and the official trimspace), but it doesn't seem to work

noSpace := strings.TrimFunc(repositoryInfos, func(r rune) bool {
            return !unicode.IsNumber(r)
        })

If someone is around to help, interested 😇

[still garnet]

Trim only cares about beginning/end, and all those are in-between, so you probably just want a replace function

i don't know of a character filtering func offhand though 🤔

[civic yacht]

https://pkg.go.dev/strings#ReplaceAll can you use this and set new to ""?

[still garnet]

maybe this?: https://pkg.go.dev/strings#NewReplacer strings.NewReplacer(string(10), "", string(32), "")

[tepid nova]

Anything I should prioritize reviewing? Other than 3560 (host API) I'm already on that

[obsidian rover]

Thanks 😍 It's the only thing that worked. I tried Replace, and ReplaceAll, doesn't work 😿

I resigned myself to do a regex on that string, that's the only thing that worked ... This is cleaner

[still garnet]

neat. i've never used that interface before

engine internals termonology

[wild zephyr]

👋 @wet mason I recall that in one codegendemo you showed a way to see the underlying graphql queries the SDK was doing. Do we still have that capability?

[tepid nova]

@wild zephyr I opened an issue for a low-tech solutio to this 🙂 https://github.com/dagger/dagger/issues/3561

[wild zephyr]

thx 🙏

[civic yacht]

Anything I should prioritize reviewing

[wet mason]

@civic yacht FYI https://github.com/dagger/dagger/issues/3558#issuecomment-1295343511

@civic yacht Also FYI -- I reworked the dial-stdin. Then got stuck -- not sure what it means for multiplexing, how many times commandconn re-spawns the binary, performance, etc

I'm postponing this for a bit but I'll need some help to talk this through

[bronze hollow]

One of the downsides to the Go SDK - we don't get the running logs from the containers

[wet mason]

dagger.Connect(ctx, dagger.WithLogOutput(os.Stderr)) <-- this should get you some stuff

[bronze hollow]

😮

Please stand by 🙂

That's awesome

Thank you

[wet mason]

sure!

More discussions here: https://github.com/dagger/dagger/issues/3587

[tepid nova]

Now that we have one major API improvement merged (https://github.com/dagger/dagger/pull/3560), it seemed to make sense to prepare a milestone for a Go SDK 0.4.0 release: https://github.com/dagger/dagger/milestone/10

[wet mason]

@civic yacht @tepid nova @still garnet @rancid turret I have a semi-working implementation of "hide the ID" thing 🙂

[tepid nova]

We have an outstanding bug report on Go SDK, 3 days old: https://github.com/dagger/dagger/issues/3551

Request for feedback on throwing our first issue party 🙂 https://github.com/dagger/dagger/discussions/3594

[bronze hollow]

codeDirectory := client.Host().Directory(dagger.HostDirectoryID(path)).Read()

Are there any limitations on what that path can be?

I'm getting "NotFound: no access allowed to dir"

[still garnet]

@bronze hollow currently you have to pre-configure dirs like dagger.Connect(ctx, dagger.WithLocalDir("foo", path)) and then do client.Host().Directory("foo") - that'll be changing in the next release

[tepid nova]

For terminology discussion: https://github.com/dagger/dagger/issues/3595

[bronze hollow]

OK. I got my monorepo working with the Go SDK (Only one service but built from two locations)

It's not bad, but the dir stuff is a little awkward

Dropped a message in #1034366157156790293

It was really easy to get Doppler and Pulumi working. with the Go SDK too 🙂

[wet mason]

@still garnet @tepid nova @civic yacht @rancid turret Thoughts on the "synchronous" part of https://github.com/dagger/dagger/issues/3558#issuecomment-1295343511 ?

Basically:

• Make ID synchronous (consistency with all other scalar resolvers that return an error -- right now ID is the only lazy special case)

• Have an option in ID to be lazy. This will be used by codegen (needs lazyness). Alternatively, there's a special field for lazy (e.g. serialize)?

• We codegen func (*r <T>) Sync(ctx) (<T>, error) (or something) to force evaluation in an explicit way

e.g.
c := container.Exec(...) -> async
c, err := container.Exec(...).Sync(ctx) <-- sync

Right now, without this, people are just calling Stdout().Contents(ctx) or whatever and throwing away the result (doing this in our magefile)

[still garnet]

that all feels intuitive to me 👍 i'm searching for a better name than Sync but nothing is coming to mind

[tepid nova]

Tried my best at contributing to the conversation without derailing the whole thing: https://github.com/dagger/dagger/issues/3558#issuecomment-1295639160

[civic yacht]

My vote is for an optional arg on ID to enable laziness. We shouldn't expect users to need this at all, so that feels like the most minimalistic change.

@wet mason quick fix to codegen issue I encountered in multiplatform: https://github.com/dagger/dagger/pull/3596

[wet mason]

done

[oak sandal]

This might be too far in the future but I was wondering about it. Considering dagger ecosystem is going to be multi-lingual, would there be a marketplace equivalent of Github actions? Basically, if I want something to run in my pipeline someone else has already created in different SDK than my codebase, how would I run it?

[wet mason]

Yes.

It's all very experimental for now and UNFINISHED, but we call those "extensions". There's some rough support in the codebase already, but it's not advertised in the docs/elsewhere (because it's very rough and, again, unfinished)

But the idea is that you can write an extension in any language. And anybody can import that extension, no matter the language they're using.

[for next week] @civic yacht @still garnet @rancid turret I patched upstream graphql-go to keep the argument ordering as defined in the schema: https://github.com/graphql-go/graphql/pull/654

I tried locally to codegen using it and it works

HOWEVER -- the upstream patch is a breaking change, no way it's getting merged. So either we maintain a fork or we find another solution

[tepid nova]

What @wet mason said. It’s coming 🙂 And that’s where everything clicks together 🪄

[verbal scroll]

If I wanted to get an early jump on writing some dagger “extensions”. Where would I look to get information on getting started.

[oak sandal]

Nic's doing a livestream on dagger.
I've literally picked up Go just watching his videos, really an amazing person. He's doing a stream after a year , so I guess he's excited about Dagger too.
https://www.youtube.com/watch?v=w-3K8in9jb4

[civic yacht]

If I wanted to get an early jump on

POC of Wasm support for dagger: https://github.com/dagger/dagger/pull/3603

[wet mason]

Late night idea: so what if we take a shortcut and bundle buildkit with the engine and run it as a container with -v /:/host (and prefix llb.Local calls with /host under the hood)? How terrible is this?

Con: “host” access is limited to the host running the engine, not the host running the SDK. Performance?

Pro: We get to run the engine as a container in a matter of hours, not weeks/months. We get to shift to this architecture right away (for the first non-Go SDK), rather than figuring out a way to distribute engine binaries somehow

Wasn’t an option before, but with the host directories work of last week it’s now possible since we don’t need to define local dirs ahead of time

[civic yacht]

Engine

[rancid turret]

Same here

[still garnet]

pushed a fix for this, ran into it over the weekend: https://github.com/dagger/dagger/pull/3602

[tepid nova]

Should we cut a release to get the new host API goodness into the hands of the community ASAP?

[still garnet]

@tepid nova I've got one more thing to double check, will follow up soon: https://github.com/dagger/dagger/issues/3311#issuecomment-1292800311

ok just checked and it seems fine (existing tests would be failing) - I do think we should get the above bugfix in too though, it's easy to run into

[tidal spire]

Chatting with @ancient kettle earlier he said in an old version of dagger we had an example pointing the engine's opentelemetry at jaeger. Is that currently possible with 0.3?

[wet mason]

I'd like to get "pass by object" (e.g. no more IDs) and "keep arguments in the schema order" (consistency) in since it's all breaking, might as well break all at once

[tepid nova]

Works for me, depends how short term those things are I guess

btw I know technically semver requires changing major version number at breaking change... But pre-1.0 is a special case IMO because the conventional meaning of 1.0 is not compatible with semver

In other words: everyone OK with calling it 0.4.0 even though it has breaking changes?

[ancient kettle]

From semver.org

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

I think we're more than good. 🙂

[tepid nova]

Ah 🙂 perfect

[tepid nova]

Actually I think we should cut a release no later than tomorrow. Today would be better IMO.

Combining breaking changes to limit the pain makes sense in general, but we have almost zero users so in this case I think it actually makes more sense to get changes out as fast as possible, to reduce the number of breaking changes encountered by users in average. If we release the new host API now, it will actually result in less pain overall (assuming we are getting a significant number of new users every day)

[wet mason]

https://github.com/dagger/dagger/issues/3617

@civic yacht @still garnet Does maintaining a fork of graphql-go still sounds like a good idea after the weekend?

[still garnet]

as long as we don't need a replace 😛

[wet mason]

hell no 😛

[wet mason]

It would contain this change for now: https://github.com/graphql-go/graphql/pull/654
Probably more after

[civic yacht]

Yeah, given lack of activity in that repo it feels inevitable anyways

[wet mason]

If we're not feeling it, I'll rewrite codegen to work on the SDL directly

[wet mason]

Agree on tomorrow (or even today)

https://github.com/dagger/dagger/pull/3598 <-- @civic yacht @still garnet @rancid turret should we get this merged before then, or need more time to review / understand the consequences?

[civic yacht]

Looking at it now

[wet mason]

We should probably get this one in as well: https://github.com/graphql-go/graphql/pull/642

it's a 2 months old CVE -- still not merged

[tepid nova]

@wet mason personally I would merge each PR exactly when we feel it's ready to merge. Release timing should not affect it either way, since we are free to release as frequently and early as we want at this point

For the ID thing, obviously I'm eager to have that improvement, but I'm assuming there's some sort of one-way door in those solutions, I wouldn't mind getting a quick live discussion before merging just to understand the tradeoffs there

[still garnet]

i'll start adding my relevant PRs to the Go SDK 0.4 milestone (https://github.com/dagger/dagger/milestone/10)

[wet mason]

@civic yacht shall we merge this now? or still waiting for some feedback https://github.com/dagger/dagger/pull/3119

[civic yacht]

@still garnet did you want to take a look first? If not I'll merge

[wet mason]

if you have some time to take a look it would be great

[still garnet]

checking now!

[wet mason]

thanks!

[still garnet]

approved 🙂 API makes sense to me, also cool seeing the internal changes (less need to pass platform around all over the place)

[civic yacht]

Had to resolve a conflict and wait for tests, but now finally merged 🙂 Thanks for the reviews everyone!

[hasty basin]

Why is this IDE complaining when the signature of Exec does have ctx context.Context?

is that gopls getting confused? https://pkg.go.dev/golang.org/x/tools/gopls
it seems to thing ctx in being used in the place on opts in the signature.
func (container *Container) Exec(ctx context.Context, gw bkgw.Client, opts ContainerExecOpts)
https://github.com/dagger/dagger/blob/main/core/container.go#L647

[tidal spire]

signature of Exec does have ctx context.Context
It shouldn't, where are you seeing that?

[wet mason]

@civic yacht @still garnet I'm doing the recursive stuff to get rid of ID in option structs (for optional fields), but there's one problem though: top-level query fields (e.g. file, container, directory) now take a File, Container, etc as argument

I can fix it with some weird special casing, not sure if it's worth it though. Thoughts?

[civic yacht]

So in order to create a File you have to provide a File and so forth?

I forget if @ancient kettle needs the ability to explicitly use IDs at any point for dagger-cue, that's the only possible use case I can think of that might mean it's worth fixing

most users of the SDK should not needs those top-level apis anymore though as far as i can think

[ancient kettle]

It’s possible I could do something else… but for now I am shoving IDs into the Europa structs.

[wet mason]

Yeah, thought so too ... I just pushed an update to #3598 (managed to support objects instead of IDs in any place without losing concurrency, although I can no longer do the sync.Once trick I think)

However, got immediately stuck with netlify trying to resolve a secret by ID

I don't know if the answer is we should keep that, or in XDX netlify should just be able to take a *Secret as argument and go

@civic yacht It did work though, I just rebased 🙂

[civic yacht]

I'd like to keep the existing extensions around, but there's no need to maintain things like that, especially since secrets are probably going to change a lot anyways. Honestly now that we have code-first schemas it would be great if when you take a secret as an arg the server plaintexts it for you and give it direct.

[wet mason]

quick q: i'm converting platform_test.go, not sure what this is for:

WithMountedDirectory("/out", "") --> scratch?

[civic yacht]

Oh yeah, that's just how I did scratch there out of convenience, now it can just be c.Directory() so pretty much just as convenient and also comprehensible to read 🙂

[wet mason]

👍

[wet mason]

ugh -- of course the marshaller is panic'ing 😄

[ancient kettle]

I'd like to set up a time to chat with people in the community who are interested in a CUE SDK for the latest 0.3+ APIs. Let me know in this thread if you're interested, so we can figure out timing and such!

[wet mason]

I just pushed a nasty workaround (separate commit) to keep those scalar based (e.g. File(id FileID))

Not proud of it, but it is what it is. Wondering if we're going to get rid of those ID-based selectors altogether in the future

At least for now nothing breaks (including netlify's secret lookup) -- I think we need to address that (secret management) and hiding IDs in XDX before we can remove top-level ID lookups (otherwise it's impossible for an extension to take a DirectoryID as input -- there's no way to retrieve the underlying Directory back, and there's currently no way to take Directory as input directly)

[wet mason]

@still garnet hey quick q on examples_test.go -- it's a different package, so it's being ignored by go test (I realized I broke everything but tests are green).

Is the different package on purpose?

[still garnet]

@wet mason it's just so that the examples are using e.g. dagger.Connect instead of just Connect which might look misleading in godocs

[wet mason]

(not sure how go doc examples work 🙂

[still garnet]

it shouldn't be ignored by go tests 🤔 i've run them myself

[wet mason]

oh nevermind

I wrongly assumed

it's just that, somehow, the PR didn't break them

impressive

[wet mason]

@civic yacht btw — I had a major rewrite of the commandconn PR ongoing, in my git stash somewhere.

It was broken though and I hit some major problems (IIRC I pinged you about those, like spawning a command for every single query etc)

Nothing major and if you’re reworking those bits I can port it over

(Saw you commenting on that one — I was halfway then I dropped it to work on hiding IDs)

[civic yacht]

Oh nice, I was commenting on it because I used the code in that PR last night when experimenting w/ -v /:/host. It worked, I didn't think it was spawning a command for every query but I may have just not noticed?

[wet mason]

TLDR: 1) when testing, I noticed a lot of weirdness — slow downs, etc. I was trying to figure that out 2) docker’s commandconn discards stderr altogether. I copied the code to our repo and patched it so we can redirect logs to dagger.WithLogOutout

[civic yacht]

Haha I copied their code for the exact same reason

[wet mason]

😂

[wet mason]

I realized the code in that PR is broken (I think there’s a message from @rancid turret saying it panics?)

So was rewriting. Then hit slowness, etc

I was nowhere near done so fill free to take that over

The main thing that did work was the commandconn stuff 🙂

[wet mason]

Tried to run our mage with nothing and then with DAGGER_HOST, weird things happened

[civic yacht]

Okay sounds great! I'll do that. Btw, have we looked into integrating that with nodejs/python yet (would cc Helder but it's late)? I'm guessing we'll need the equivalent of commandconn in those SDKs too

[wet mason]

Yeah. I think it’s best to use Go as a test case and then apply to others.

Waiting on your findings on the engine as container — if for instance it’s possible for the engine to be a long running container; then we don’t need commandconn I guess? (Well, we need it “less”)

“less” as in we could tcp to get started, commandconn later

But if exec ing the binary is the only way, then we need commandconn right away

(I did read you mentioning sessions etc — do you think we should go with exec for now and figure out the rest later?)

[wet mason]

@civic yacht @still garnet we're the proud new owners of a fork of graphql-go ...

I re-opened the upstream PR here: https://github.com/dagger/graphql/pull/1

If we still think it's a good idea, I'll change dagger/dagger to use it instead

[wet mason]

err ... do replace directives work across go get? or do I need to change the import path everywhere?

[still garnet]

pretty sure you need to change import path

[wet mason]

dang

I did that, but then realized that there's a few dependencies (e.g. graphql-go/handler)

we'd have to keep 3 forks ... 😐

graphql, graphql-go-tools, handler

[still garnet]

ouch

should we just vendor?

not like, go vendor, but just yoink them into subpackages

is this a dependency of the engine or the sdk?

(assuming split/remote/not-embedded engine)

[wet mason]

engine

basically, it changes graphql-go's API to pass arguments as an array rather than a map -- to keep ordering as defined in the schema

but graphql-go-tools (used for stitching) also needs updating

and graphql/handler takes a github.com/graphql-go/graphql.Schema as input

[still garnet]

well, if it makes you feel any better we might want to fork the handler anyway

i've been looking for a way to pass a value as a header and pass it to the router, and I'm not seeing anything yet. (the value is something like a session ID, but for filesyncing)

unless y'all have any other bright ideas for that

(actually, how does something like this handle auth...?)

i guess you can just put it behind an auth checking reverse proxy

[civic yacht]

It's a while ago now but I did something like that for the old implementation of multiplatform w/out forking. I think these are the relevent parts of the code:

• https://github.com/sipsma/dagger/commit/aecc4324686def905ac78c6fca2d1d10df0717a6#diff-c399d26e7f23b713ce01946ac9e0e6f1fc94d692e8a086180191901da91b6964
• https://github.com/sipsma/dagger/commit/aecc4324686def905ac78c6fca2d1d10df0717a6#diff-004cf8cc052417c7e662acef5abfa4e44b7c6778f9edc6c43616a06b703f306a
  Don't know if it can be re-used for what you're doing, IIRC it wasn't feel-good code to write, hack-ish

[still garnet]

a ha, good old context.Context 🙂

[wet mason]

you know what -- I'll fork graphql and graphql-go-tools, but for handler, i'll just copy it in our codebase (router/internal/handler or something)

the handler has a bunch of code -- most of it is graphiql/playground related, but we're already using our own implementation, there's little we are using from that package (one file and tests)

[wet mason]

@still garnet I just updated all tests ... it now looks like this c.Directory().WithDirectory("with-dir", dir)

I don't know which one was more intuititve, directory first or path first

anyway 🙂

[still garnet]

just saw the PR

one argument for source first, path second: it's the same as cp, ln, and I think mount --bind

[wet mason]

I think this was for consistency with WithFile, perhaps?

I'm fine either way -- the PR makes it "as the API author intended", just wanted to double check that's what you intended 🙂

[still garnet]

you'd have to ask @tepid nova for that 😛

seems like WithCopiedFile (now WithFile) should also have its args flipped tbh, but i won't die on this hill if others disagree

[wet mason]

It's everywhere:

WithMountedFile(path string, source *File)
WithMountedCache(path string, cache *CacheVolume)

I think it makes probably more sense for X to be the first argument in WithX

[still garnet]

yeah, this will mean breaking more APIs than the one we originally intended to fix, but i think it's better 😛

(turns out WithMountedCache was right all along...)

[tepid nova]

https://tenor.com/view/kermit-awkward-smile-gif-24502300

[still garnet]

@wet mason btw are you using gofmt to update all the code? could save you a ton of time if not

[tepid nova]

what’s the question? intent behind order of args?

[wet mason]

I should, but no -- vscode multi-edit

[still garnet]

i think something like this should work: find . -name '*.go' | xargs gofmt -l -w -r 'x.WithMountedFile(a, b) -> x.WithMountedFile(b, a)'

[wet mason]

neat!

[wet mason]

Yeah. PR is in to keep go args in the same order as API (instead of sorting)

[wet mason]

which resulted in this

[wet mason]

and this is the question ^^^

[tepid nova]

I will share my patent pending design process for arg order but please do not share it’s confidential

https://tenor.com/view/roll-dice-roll-the-dice-gif-7337987

[wet mason]

live usage (from unit tests):

c.Directory().WithDirectory("with-dir", dir)

felt weird when i was rewriting. But not too weird, just wanted to double check

that being said -- it is pretty consistent. Path is always first

¯_(ツ)_/¯

[still garnet]

btw: the removal of ID is great. there was a time where I typed e.g. WithDirectory(dir, "dest/path") and it interpreted "dest/path" as a DirectoryID const 😱

...which is partly what set me off on this "all the arg orders are wrong" line of thought, since it's what I typed first

[wet mason]

the good old rite of passage of the SDK

[still garnet]

is it time for a community poll? 😄

jk, i'm good with shipping the smaller change in 0.4 since these are obviously the odd ones out

[wet mason]

I'm fine either way, I can see an argument for both. To me WithDirectory(dir, path) makes more sense. However then it's WithoutDirectory(path) which is not very consistent

[still garnet]

i think that's OK - umount just takes a path for example

[civic yacht]

We can generate one SDK for every permutation of arg ordering

[wet mason]

with replace statements

[still garnet]

just change it to a map!

[wet mason]

"how to get hate mail in 3 simple steps"

[wet mason]

it used to be a map -- I can just revert so the order changes everytime we codegen again

I'm going to merge as is if someone could review (since this is the smaller delta), then we still have some time tomorrow to change our mind before cutting the release

[still garnet]

reviewed+approved

btw - do we need to retain license/copyright?

for the handler bit that we vendored

[wet mason]

I'd say eventually we should put something like go-chi/chi in front as a middleware -- handles logging, auth, rate limiting, whatever

but it's all context based

(compression wouldn't hurt for instance)

[wet mason]

good point, checking

[still garnet]

here's what I did for filesync: https://github.com/dagger/dagger/blob/main/engine/filesync/NOTICE#L1 + https://github.com/dagger/dagger/blob/main/engine/filesync/BUILDKIT_AUTHORS

authors file generated via git log --format='%aN <%aE>' . | LC_ALL=C.UTF-8 sort -u

i'm not a lawyer, but at least i can say i tried

[tepid nova]

@wet mason @still garnet @civic yacht @hybrid widget any thoughts on a Go SDK 0.4 release note? The changes are pretty substantial (exciting new features + breaking changes). It feels like it deserves a substantial note.

• Who should write it?
• Where should we post it?
• What should the content be?

[wet mason]

@tepid nova Copy pasting my message about splitting “sending the query” from “building the query” in the SDK DX here to avoid hijacking the other thread:

It’s tricky though. “Sending” doesn’t necessarily equal to “Executing”. Like if you just “send” an exec, nothing happens (how LLB does it — Solve() of llb.Run doesn’t do anything)

As confusing as the current API is, at least we managed to hide that complexity: the codegen functions that “send” (the ones that return an error) are strategically placed on functions that “execute”: you can’t end up in a situation where you send without executing (except for ID)

If we “just” split build and send it gets more confusing than today because whether it execs or not will depend on which incantation of fields you requested back

So we’ve got to figure that out

Another, smaller problem: DX for getting values back. Right now the best DX there is is the one you proposed, and I can’t find a better one. There’s a few drawbacks which I think make the day to day less joyful: you’ve got to declare your variables in advance, you don’t get any code completion when you do that, the variables contain garbage until you hit send (easy to misuse), etc

Lots to think about — there must be a way to make this much more self explanatory

Release Notes

[tepid nova]

I noticed that the Github dependency graph for the dagger repo (visible in the web ui) lists a bunch of Go packages in the top-right drop-down menu, none of which are the correct one...

[hybrid widget]

Will the new version of the SDK include the new host API from @still garnet? If yes, could someone please review this in-flight PR at the time of release to ensure it's still accurate, as I would like to release this guide at the same time: https://github.com/dagger/dagger/pull/3627

[tepid nova]

yes it will

[wet mason]

Yes -- also this one https://github.com/dagger/dagger/pull/3598

It should mostly simplify the guides, less code

I've updated the existing snippets in #3634 already

[obsidian rover]

We also track dependents from the dagger-go-sdk repo, as we did not know how GitHub would react

[tepid nova]

Btw @obsidian rover did you know the Go package registry also exposes a list of downstreams?

I just learned that yesterday

[obsidian rover]

Do you mean this link: https://pkg.go.dev/dagger.io/dagger?tab=importedby ? Might be interesting to track it too, you're right.
Will do, thanks

[tepid nova]

What's interesting is that it's a completely different list. It looks smaller? If it's not too hard, yes I think it would be good data to have.

[obsidian rover]

It looks smaller yes, but it's indeed different, you're right. Consider it done 😇

[tepid nova]

“pipeline builder”

[wild zephyr]

I noticed that the Github dependency

[still garnet]

@wet mason just fyi all my PRs are merged now 👍

[twin crow]

@still garnet @civic yacht if one of you have some spare cycle, there is a blocker that you could help with for dagger-cue: https://github.com/dagger/dagger/issues/3442#issuecomment-1299513008

[still garnet]

i was about to write a comment for https://github.com/dagger/dagger/issues/3629 that's related, since this is another path where we possibly want to support engine -> client requests

so that'd be more along the lines of option 1

but that's obviously longer term

i'm knee-deep in 3 codebases at the moment trying to figure out how this could work (buildkit, buildx, moby)

[wet mason]

Right -- I figured we're going to be something better for secrets, eventually. Extensions or client-side. But definitely not what we were doing in 0.2.x (addSecret) and definitely needs lots of design work. Was wondering what we could do instead to unblock porting the CUE SDK: bring back addsecret in the public API (bleh), have CUE SDK use a "hidden" API (meh), find other workarounds...

[still garnet]

yeah, option 2 isn't very enticing because even if it's hidden it still puts up appearances that it's safe to use (albeit within only one group of users)

[wet mason]

@still garnet btw did you hit this problem with the bass integration of dagger?

[still garnet]

it's one of my last failing tests 😛

[wet mason]

yeah, well, same with CUE SDK 🙂

[civic yacht]

commented with one possible alternative (pretty sure it's a really bad idea but want to double check) https://github.com/dagger/dagger/issues/3442#issuecomment-1300937785

[wet mason]

@still garnet and hostdirectory .secret is gone correct?

[still garnet]

that was gone for unrelated reasons, it was just redundant with hostdirectory.file.secret. so now that's host.directory.file.secret

[wet mason]

ha! was about to suggest this, but with files (hence the hostdirectory .secret question)

[wet mason]

oh yeah neat

[civic yacht]

Ah sure that'd work too!

[wet mason]

so uhm ... write secrets to /tmp, load them back? how long until the pitchforks 🙂

@civic yacht just to avoid the fork thing

[still garnet]

lol, nailed it

[civic yacht]

I don't know if writing the secret to a file is worse than potentially accidentally leaking them through a fork

They both are bad in their own special ways

[wet mason]

🥔 🥔

[still garnet]

maybe you can make them all fifos so they "burn after reading"

does that even work? 🤔

[civic yacht]

If I had to bet no, but it would be cool if it did

[wet mason]

yeah that'd be great

[civic yacht]

fsutil would have to stream the fifo i think

[wet mason]

to "hide" them a little bit -- do that in a c.Directory(), not on the host

[still garnet]

right yea, it'd be nice if it read it as a regular file but it might try to preserve the fifo aspect

[wet mason]

maybe in a mount or something, would that work?

[still garnet]

but then this results in the secret value being embedded in the SecretID 😛

[wet mason]

tmp mount? i guess not? won't be able to read back

@still garnet right

[still garnet]

i mean, that's probably fine if the user "just" doesn't leak it (assuming we don't systematically somewhere)

since the end goal is to just avoid it showing up in layers/etc

[civic yacht]

I've always wondered if you could create a memfd and then do a localdir sync of it from /proc/self/fd/N, but that's reaching new heights of stupidity

[still garnet]

i'll post a summary of these wild thoughts to the issue

[ancient kettle]

Thanks for all of the ideating around this, @wet mason @civic yacht @still garnet. I'm sorry I missed it while I was out on some errands. I'm tempted to try @civic yacht's of creating environment variables...

Also, @still garnet's suggestions are a potential way I could go about this... not my favorite, to be honest, but manageable, especially for the short term.

It all has me very curious about what secrets in Dagger looks like long term.

[still garnet]

i'm pretty bullish on having a pluggable secret provider for dagger.Connect, long-term

[ancient kettle]

I rather like this idea, personally. Being able to have either an in-memory map of secrets or access to a HCP Vault instance (or any other secret store) sounds awesome.

[wet mason]

@rancid turret Go SDK examples: https://github.com/dagger/dagger/blob/main/sdk/go/examples_test.go

[rancid turret]

Nice 👍

[wet mason]

Very basic, but does the job

[rancid turret]

Yes, very easy to port.

[wet mason]

@rancid turret @mellow bolt @tepid nova I want to get a discussion started on implicit/explicit, right now the discussion is fractured between https://github.com/dagger/dagger/issues/3555 and https://github.com/dagger/dagger/issues/3558 with lots of comments

Should I start another issue or continue in #3555?

[tepid nova]

Well 3555 is more on-topic, right?

[wet mason]

Yep

I'll continue there

[tepid nova]

If there's relevant content from 3558, maybe just quote it in 3555 so we have all context, and then yeah continue in 3555

[wet mason]

@civic yacht @still garnet @hybrid widget @tepid nova ok to cut a 0.4.0 release now? anything we are waiting for?

[still garnet]

:shipit:

all the host API PRs are in

[civic yacht]

Yeah should be good, doc updates are still in PR but that doesn't need to be in lockstep i don't think

[wet mason]

Merged the docs PR and addressed my own comment in a follow up PR: https://github.com/dagger/dagger/pull/3643 /cc @hybrid widget

https://tenor.com/view/train-steam-gif-23821904

release train inbound

^^ /cc @tidal spire @hasty basin

[tepid nova]

good to go 👍

https://tenor.com/view/missed-train-late-funny-closed-doors-hanging-on-gif-15495155

[wet mason]

is that the "hide IDs" PR hanging in there?

[wet mason]

Can I get a quick review on this one?

Just removed the ID() reference in the docs -- it's no longer in the snippet

[rancid turret]

I ported all those examples pretty quickly. Most passed but I have a bug in deserializing some objects (Directory). This is the part I already knew I need to test more (deserializing responses). I'm loving the flow, and the type hints are really helpful letting you know something is not quite right while you're writing.

async def test_directory():
    async with dagger.Connection() as client:
        dir = (
            client.directory()
            .with_new_file("hello.txt", "Hello, world!")
            .with_new_file("goodbye.txt", "Goodbye, world!")
        )

        entries = await dir.entries()

        assert entries.value == ["goodbye.txt", "hello.txt"]

[tidal spire]

ship it!

[wet mason]

https://github.com/dagger/dagger/pull/3644 <-- documented the wonky release process (it should be automated, but for now it should be at least documented -- I think there's only me and @civic yacht that know how to release)

... and I already had forgotten half of it 🙂

• ✅ engine v0.3.3 is out
• ✅ Update Go SDK to Engine v0.3.3: https://github.com/dagger/dagger/pull/3645
• ✅ Go SDK v0.4.0 released https://github.com/dagger/dagger-go-sdk/releases/tag/v0.4.0
• ✅ Docs are live: https://docs.dagger.io/sdk/go/959738/get-started/

[tepid nova]

No 0.4?

Oh sorry engine vs go sdk gah

(The abstract tradeoffs of coupled vs decoupled releases, becoming tangible before my eyes 🙂

[wet mason]

😄

Yeah, and yesterday's concerns about docs release coordination with multiple SDK versions

so far it's not being too much overhead

[tepid nova]

Honestly I think that might be actually fun to do with Dagger, for real (famous last words)

[wet mason]

btw -- that monorepo decision saved me a couple of times already. Hiding IDs would have been a cross repo nightmare effort

[wet mason]

Yeah -- although there are a few bits "out of scope" for dagger. Like that "asynchronous event loop" we talked a long time ago if you recall

Do this -> Open a PR -> When the PR is merged, do this -> ...

(e.g. there's parts of the DAG that might be running for days, which is out of scope)

[still garnet]

just do it with bass loop once i finish the dagger runtime 😈

[tepid nova]

Yeah I was picturing a more narrowly scoped pipeline that, given a git remote (by default github.com/dagger/dagger), fetches all the right directories from the right tags, then builds and deploys the stable docs.

[wet mason]

^^^

@tidal spire examples ready to update 🙂

[tepid nova]

Then in CI we just trigger that pipeline on a "new tag" event or something

That way no weird async event loop

It's just the multi-tag build primitive that's a pain without dagger

(unless docusaurus itself can be configured to do that, but I doubt it)

[wet mason]

That looks awesome 🙂

Go needs more tests too -- right now it's cheating because the Core API is tested using the SDK, so we get that test suite for free

But there's a few edge cases you did catch (array of objects I think?)

[still garnet]

i think that part had tests too (container publish + multi-platform)

container export + multi-platform

at first i was worried that having the core tests use the SDK was a bit scary (pretty leveraged/circular!), but now you'll have to pry it from me, feels like an efficient way to test both

[tepid nova]

Merry christmas https://github.com/dagger/dagger/issues/3555#issuecomment-1301327344

https://tenor.com/view/kermit-water-ice-bucket-challenge-cold-gif-14314907

[cosmic cove]

https://tenor.com/view/smirk-ron-swanson-parks-and-rec-smile-gif-20933902

Hey team - Please add any demos or new updates to the community call agenda for tomorrow -https://docs.google.com/document/d/1-6RSWHwFoZr588kftPLVvT1RCHUrOrnmURldBRrP1Ak/edit#heading=h.jtc025amazve

[wet mason]

I don't want to reply to that issue right away to avoid comment explosion right away. So quick comment here:

pipeline := dagger.Container().
  From("alpine").
  Exec([]string{"ls"}).
  GetExitCode(&lsCode).
  GetStdout(&lsStdout).
  Exec([]string{"echo", "something", "else"})

stdout is a File -- what we want is getting the contents field of stdout

Any idea on how to update that snippet to reflect this?

(stdout is just a convenient example of composition -- there's plenty other similar -- so making stdout a string is not the answer :P)

[fair ermine]

Adding a method GetFile(path string) that returns a dagger.File and then you can call Contents?

However, it makes the code too verbose IMO

[wet mason]

Then the chained GetStdout won't work because there's no stdout on a dagger.File

[ancient kettle]

So... a thought... (and not one I feel 100% on, but maybe worth getting out there): could we return an object from Exec? That would include ExitCode, Stdout, Stderr and a Container object that could be further chained?

The problem I see with that is we'd lose chainable parallelism.

And we'd always have to pay the penalty of returning ExitCode, Stdout, Stderr

😕

It definitely seems like we’re not having an easy time getting the best of all worlds… parallelism when we want it, and easy access to various resolved scalars when we want it.

[fair ermine]

Maybe move to an explicit approach could help to choose

[tepid nova]

Mm didn’t think of that. I see a good answer in option 3 (collapsed output): treat the file as the output, replace o.GetString() with o.GetFile()

Last task of the day: write an updated proposal for CLI packaging, which is a must-have dependency for Python SDK, NodeJS SDK, and GraphQL API launch.

Mostly the proposal is a recap of options we already discussed, but cleaned up and updated, with clear next steps.

cc @wet mason as you mentioned it this morning. Sorry it took me so long to get to it.

[rancid turret]

@wet mason I just came quickly to try to fix this but actually there's no bug. Looking at the error, I just ported with the hidden IDs and I don't support that yet 😅 There's just two failures now:

1. Getting conflicting fields in ExampleContainer_WithMountedCache from those exec in the loop;
2. Getting a timeout on the ExampleHost_Workdir. Any idea?

[tidal spire]

PR for examples repo: https://github.com/dagger/examples/pull/6
I've updated and tagged my repos: dagger-demos, greetings-api, hello-monorepo and the new hello-do
Looks like the getting started guide is up to date
Anything I've missed?

[fair ermine]

I approved your PR, I let @hasty basin double check but that looks good

[grave stump]

Is it possible to include the .git directory in the repo tree from the dagger client git clone?

[hasty basin]

We'll answer over here: https://discord.com/channels/707636530424053791/1037710136346685460

[grave stump]

Thanks

[simple lily]

Hello i'm trying to figure out what Cloak is. on this page here links to the cloak branch in the dagger repo but it's 404ing for me 🙃 is there a different branch I could check out?

[obsidian rover]

Hi, cloak was the name of the internal experimentation around all the multilanguage SDKs. It was mostly the Go SDK, which we renamed to Dagger Go SDK afterwards

[simple lily]

ah okay! that makes sense. much appreciated 🙂

[tepid nova]

Sorry about that. Did you get that URL from our vmware presentation? Or somewhere else?

[simple lily]

I think what happened was that I saw that it was mentioned somewhere in the help channel, then I googled it and found that page.

[tepid nova]

@cosmic cove could we redirect that url to the go sdk blog post?

[wild zephyr]

doing this. Should take 1m

[wild zephyr]

done

[wet mason]

Quick docs update from your demos @rancid turret @tidal spire: https://github.com/dagger/dagger/pull/3661

[tidal spire]

here's the update to the example we coded live https://github.com/dagger/examples/pull/7

I can update the concurrency stuff in the guide. Basically delete the last step, small tweaks to the other steps, and make a note about how it's all happening in parallel

[wet mason]

That's awesome 🙂 That, plus the removing ID(), plus @still garnet's changes to remove Mkdir, plus @civic yacht's work on removing go mod edit -replace -- the docs will be tiny 🙂

[tidal spire]

I think it'll make them feel like a more approachable "getting started"

[tepid nova]

OMG I forgot about that. Go SDK will use the helper too, and no more replace?

That's huge

[wet mason]

That's in @civic yacht's PR already 🙂

[wet mason]

Instead of that boilerplate, we could squeeze in more explanations on the programming model (how parallelism works, etc)

[civic yacht]

Yeah use of the helper is in there, technically I didn't rm the replace yet just cause I didn't get to it, but I'll break out the champagne when I do

[wet mason]

Yes keep it for last 😄 git commit -m "🍾"

[tepid nova]

And maybe a mermaid visualization of the DAG? 😇 (doesn't have to be generated)

[wet mason]

I think that would basically be "explain the programming model in one mermaid instead of a thousand words" kind of thing

[tepid nova]

Yes exactly

Then link to the "Dagger programming model" guide for more explanation

@wet mason imagine if we have that "multi-language guides" you were talking about in the call. And every example also includes the DAG 🙂

cc @wild zephyr I know you're into that stuff too

[wet mason]

The dream

[tepid nova]

What's the process for contributing an API change? Do I re-run codegen on all SDKs? How?

[wild zephyr]

not exactly a DAG visualization but this is actually quite awesome (https://ivangoncharov.github.io/graphql-voyager/). Interesting that I haven't found any GraphQL query visualizers though...

[wet mason]

Will need to be integrated into the magefile to automate across the board, right now Go is the only SDK supported by processes

• CI will fail if you forget to generate (Go only)
• cd sdk/go && go generate . (Go only)

• processes = dev process

[tepid nova]

Thanks! Giving it a try: https://github.com/dagger/dagger/pull/3666

[rancid turret]

@tidal spire trying to wrap my head around the parallelism stuff. Can someone give me some lights? I'm up for a quick video call.

[tidal spire]

yes! I'll hop in #dev-audio

[tepid nova]

Anything I should review or unblock?

[civic yacht]

There's a fun problem around SDKs disagreeing on engine versions (totally independent of all the packaging stuff). Describe it here, comment after that is the solution I'm going with for now: https://github.com/dagger/dagger/pull/3647#issuecomment-1302618789
There's some meaningful implications, so would be good to have more eyes on it

[still garnet]

omg omg omg finally (pictured: filesyncing with remote client => dagger engine running in a container)

sorry for lack of responsiveness today, i've been really in the weeds. finally some light at the end of the tunnel

[tepid nova]

wow! pass through of buildkit grpc over ws??

[still garnet]

close, no websockets, just a Upgrade: h2c. i'm also 100% cheating by using the buildkit session implementation code in the SDK, but, baby steps.

i've had to vendor grpc and buildkit just to figure out what's barfing where at various steps 😵‍💫

[wet mason]

WOOT

[tepid nova]

impressive

[wet mason]

I opened this channel to share bad news / ask for feedback, glad to have seen this before 🙂

[tepid nova]

and promising!

[wet mason]

So ... obviously (in retrospect) we can't run dagger tests with dagger, because ... it needs dagger and tests are already running in a container

Idea: what if we do what we did for extensions, but generalize it to every exec? Basically, inject a DAGGER_HOST that talks back to itself -- dagger.Connect() would always work, even inside a dagger container, transparently

thoughts?

(and it's turtles all the way down)

I'm expecting @civic yacht and @still garnet to either be excited or disgusted by the idea, not sure which way it's leaning yet 😄

[civic yacht]

So Dagger-in-Dagger? I imagined previously we'd use services for this (run dagger remote engine in exec and share a socket to it with the "client" container). I believe I did the equivalent of that at one point in Europa, but it involved starting buildkitd in a container and then sharing its socket over a cache mount, but that was just a fun experiment and not something anyone should actually do.

[wet mason]

virtual-dagger-in-dagger -- it's the same dagger instance

same trick (and code) we used for extensions: mount a unix socket to talk back to the API, set a DAGGER_HOST

basically not making extensions a special case anymore: any container could do that

[tepid nova]

I actually thought that it already worked that way 😄

[wet mason]

@tepid nova only for extensions

[still garnet]

was about to suggest this too, it's what I did for Bass. it runs Buildkit as a service and points the test suite to it: https://github.com/vito/bass/blob/99973243f585be969e32909669405aaad1948f2c/bass/bass.bass#L132-L152

[tepid nova]

Right - I guess I extrapolated a bit from there..

Makes sense to me, my only question is how to sandbox it safely

[wet mason]

@civic yacht @still garnet to be clear -- not suggesting it should be able to launch a brand new instance of dagger/buildkit/etc from a container. I'm suggesting we allow containers to talk back to the same API instance that created them

[still garnet]

yeah, i'm good with reusing the host engine if we find a non hacky way to do it

[tepid nova]

(as reliable sandboxing + nesting is what makes our extension loading model so special)

It would be a major improvement on the state of the art of container nesting. Ie safe container nesting. (logical nesting of course)

[wet mason]

Yes, that's 100% the limitation. I'm shrugging and saying we should fix it anyway for extensions? More incentives now? 😄

[tepid nova]

Well I believe you guys already sandbox extensions right? Or am I extrapolating again and you plan on doing it but not implemented yet?

[civic yacht]

Yep, makes sense now. I can't think of any reason why it shouldn't be possible. Probably should not make it the default behavior for sandboxing concerns, but it can be a knob (maybe just a development build one)

[wet mason]

Although extensions are somewhat privileged -- the user loaded them. Here it means any random container can just use the dagger API

[civic yacht]

Extensions are just exec-ops, they are sandboxed

[tepid nova]

could be configurable in an exec opt

[tepid nova]

I mean sandboxing of Dagger API capabilities

[wet mason]

Oh I mean, an extension can totally c.Host().Directory("/etc") and go crazy right now

[civic yacht]

Oh I see, no there's no sandboxing around that yet

[wet mason]

well, with what @still garnet's doing, maybe Host() would mean the container's host 🙂

[tepid nova]

Starting a thread 🙂

[wet mason]

so sure, go crazy with your own filesystem

[still garnet]

@obsidian rover btw - tests should be fixed on macOS now, if you have a chance to confirm sometime. https://github.com/dagger/dagger/pull/3437#issuecomment-1297579980

[tepid nova]

@civic yacht I accidentally overwrote your top comment in https://github.com/dagger/dagger/issues/3653… 🤦 I’m on mobile so don’t see the option to restore your version. I copy pasted back but lost formatting… sorry!

[civic yacht]

Haha no worries, I will fix it quick, that's weird that github doesn't let you access the raw text from earlier edits... I can't just restore from web either

[tepid nova]

ok in that case I will fix the formatting

I was making cosmetic edits initially, then wrote my question in the wrong tab

@civic yacht temperature check before suggesting in the issue: would it make sense to separate dagger-engine-helper and dagger-engine-router sooner rather than later, and have the former exec the latter? Would be an incremental step towards the router migration; avoid a future drastic change in the meaning of “helper”, and since we already pull that engine image anyway, overhead of extracting one more binary (which will need to exist soon anyway) would be small.

We could do it right away for python sdk release, or 1-2 weeks later (rough scoping). One more baby step out of the way

this in turn makes me wonder if dagger-sdk-helper would perhaps be a more descriptive name, since from day one it would clearly not include engine functionality, but purely client-side functionality

[civic yacht]

Okay thanks! I was getting back to your comment on the issue in the meantime. But to answer the above, I think adding another exec would increase the complexity quite a bit. The helper itself would then have very little purpose left besides just proxying to the router.

I liked the name helper because it currently "helps" you by providing routing of your API calls (🙂 ) and in the future it may not longer do that but instead just help with some pieces of functionality we haven't implemented yet. dagger-sdk-helper makes more sense than engine-helper though, totally agree, I'll change that

[tepid nova]

do you mind if we chat live about it tomorrow? I’m hesitating between a bunch of naming & packaging options now..

Seems silly to be stuck on such a small thing but naming is weird that way. It’s small and insignificant until it’s suddenly huge and important

[civic yacht]

Yeah sounds good! I also have only very loose opinions on naming since I admittedly have much less experience with the pros and cons of naming options, so yeah I'm all ears whenever tomorrow

[still garnet]

mega early draft PR for remote sessions now that the dust has started to settle: https://github.com/dagger/dagger/pull/3671

[wet mason]

@rancid turret I've opened the PR to re-organize the internal CI pipeline to fit Python (and node later): https://github.com/dagger/dagger/pull/3672

[wet mason]

Side note: Being able to write CI code in Go is pretty sweet 🙂

Enforcing a standard structure for Dagger SDKs CI:

type SDK interface {
    Lint(context.Context) error
    Test(context.Context) error
    Generate(context.Context) error
}

[tepid nova]

Now that "project cloak" is merged, how does everyone feel about renaming this channel to #engine-dev ? Leaves the door open to perhaps creating more #xxx-dev channels in the future

Another thing we could do is create a new category "dev" or, perhaps more descriptively, "maintainers", for channels related to the development of dagger, rather than using it or developing on it. I like the collapsible nature of categories, to keep my sidebar light and clean 🙂

[obsidian rover]

Agreed, so we would collapse the maintainers and cloak-dev into one?

[tepid nova]

I was wondering about that maintainers channel. Not worrying about it for now, as everyone is busy. But yes doing that would be an option, to be discussed with @stray heron

I think the maintenance and feature development work is inextricably mixed. Personally I don't think it works to separate it

In other words discussions related to contributing a PR and reviewing it, should take place in the same place since they all involve the same people

to be clear @obsidian rover I'm talking about a maintainers "category" rather than a channel. The current #999807040039952515 could of course be moved to that category

[obsidian rover]

Ooooh, thanks for the clarification

[tepid nova]

So if someone, say, wants to make their first contribution to the engine, they would "visit" the engine maintainers at #1036545971942858812-maintainers to ask for guidance.

Engine maintainers would continue using it to discuss ideas, problems, PR review, release planning, etc

[rancid turret]

@tepid nova I'm always in favor of having more granularity in Discord, sounds good 👍

[rancid turret]

@civic yacht @tepid nova I believe there's multiple issues relating to the binary dependency for provisioning the engine in the SDKs. Is there one 💍 to rule them all? What can I use to track this dependency in the Python milestone?

[tidal spire]

sneak peek of one of next week's demos

[rancid turret]

@cosmic cove should we continue to use the cloak label in GH for issues?

[still garnet]

🎣 fishing for opinions on keeping .git dir by default: https://github.com/dagger/dagger/pull/3660#pullrequestreview-1168717091

[civic yacht]

Erik Sipsma3294 solomon4104 I believe

[tepid nova]

I find the new label area/graphql confusing. We already have area/engine, area/core, kind/api design which all overlap. If anything we should be removing labels, not adding them.

IMO we can merge the 4 labels above into area/engine (I would personally prefer just engine because I find the current label naming schema to verbose, but saving that for another time 🙂

[cosmic cove]

area/graphql is going used for the project view for the GraphQL overall launch. I'm happy to change to whatever, but just need to make sure it doesn't break views/milestones. I'll DM you.

[cosmic cove]

@tepid nova what label should I change these issues to? I will update and then update the project views with the new label.

[ancient kettle]

So, I tried this... and I'm getting failed: secret "eyJob3N0X2VudiI6ImZjZGUyYjJlZGJhNTZiZjQwODYwMWZiNzIxZmU5YjVjMzM4ZDEwZWU0MjllYTA0ZmFlNTUxMWI2OGZiZjhmYjkifQ==" not found

I decoded that base64, and it's this:

{
  "host_env": "fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9"
}

Which is the correct environment variable... and if I do an os.Getenv("fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9"), it returns the correct value.

Any thoughts, @civic yacht @still garnet @wet mason?

[wet mason]

is there a snippet of code we could look into?

[ancient kettle]

Yeah! Give me a moment.

This is how I create a new Secret:
https://github.com/jlongtine/dagger/blob/cue-sdk/solver/solver.go#L102-L120

Which I use in client.filesystem.read: https://github.com/jlongtine/dagger/blob/cue-sdk/plan/task/clientfilesystemread.go#L149-L161

And I'm trying to mount here: https://github.com/jlongtine/dagger/blob/cue-sdk/plan/task/exec.go#L103-L104

I'm currently trying to debug this test: https://github.com/jlongtine/dagger/blob/cue-sdk/tests/plan/client/filesystem/read/file/test.cue

actions.test.usage.secret is failing with the error message I posted.

[wet mason]

func main() {
    ctx := context.Background()
    d, err := dagger.Connect(ctx)
    if err != nil {
        panic(err)
    }
    os.Setenv("FOO", "bar")
    secret := d.Host().EnvVariable("FOO").Secret()
    plaintext, err := secret.Plaintext(ctx)
    if err != nil {
        panic(err)
    }
    fmt.Println(plaintext)
}

this seems to be working

[ancient kettle]

Can you try that with loading from the ID?

[wet mason]

@still garnet Depending on golangci version, sometimes I get this complaint:

core/directory.go:37:33: unexported-return: exported method Decode returns unexported type *core.directoryIDPayload, which can be annoying to use (revive)
func (id DirectoryID) Decode() (*directoryIDPayload, error) {

Ok if we make that public?

[still garnet]

I think the reason for Decode being public is just that project/ needed it, it was kind of a short-term hack. would prefer to keep Decode and directoryIDPayload private, but no big deal, no one should be using core/ but us anyway

[wet mason]

@still garnet oh makes a ton of sense -- agree it should be kept private, I'll stick a //nolint for now

@still garnet ah! my bad, you explained exactly this in a comment a few inches down my nose

[still garnet]

😆 oh, didn't remember that. np!

we did have some plans to redo project/ using purely the core/ interfaces, instead of direct LLB all over, but I've had a couple false starts with it

[wet mason]

Yeah project is going to move around -- many things it does don't make that much sense now (server side codegen etc)

Also with dagger-in-dagger being part of core, that's one less thing project should be doing

[wet mason]

did that straight in #3674 -- should have been 2 PRs, but I've been moving all CI into dagger so hitting a bunch of strange problems

@still garnet Also -- I've been using exclude/include, it's helping a lot

[still garnet]

nice nice

[wet mason]

can I get a review on #3674? it's 99% CI code that doesn't really need a review, the only meaty part is these 5 or so lines:

https://github.com/dagger/dagger/pull/3674/files#diff-10d41febe6f07f3eed32775ac5ec0a09eeda9867db7f5f3c57a39c75b90b708aR687-R697

🙏

[still garnet]

thought about exporting w/ remote engine, it's a lot harder than importing, but I think I have a plan that keeps us unblocked on upstream changes: https://github.com/dagger/dagger/pull/3671#issuecomment-1304289313

[wild zephyr]

IDK how but I want to find a use-case for tsnet in Dagger 😉 https://tailscale.com/blog/tsnet-virtual-private-services/

[tidal spire]

say no more, i'm on it 🙂

[rancid turret]

@wet mason Is there a way to exec a failing command without failing the pipeline? E.g., check stderr, retur_code. Asking for a friend 😉

[wet mason]

no 😐

except sh -c "cmd || echo MAGIC FAIL"

[rancid turret]

Ok 🙂

[wet mason]

if strings.Contains(stderr, "MAGIC FAIL")

😬

[civic yacht]

there's some issues open for all of that (just to preemptively dedupe)

[wet mason]

yep

[rancid turret]

You mean we'll support it?

[civic yacht]

it should be possible

https://github.com/dagger/dagger/issues/3192

https://github.com/dagger/dagger/issues/3025

[rancid turret]

Thanks 👍

So it's not just me 🙂

[civic yacht]

haha no, the exit code field is a little silly until we fix that

[wet mason]

@rancid turret I managed to "fix" test/generate ... now it's just failing because it can't talk to dagger (which is normal)

[wet mason]

@rancid turret #20 1.605 ============================== 54 passed in 1.07s ==============================

!!

@rancid turret I added support in the shim for automatic unix->http proxy, so the python SDK doesn't need to implement unix sockets: https://github.com/dagger/dagger/pull/3706

this is making the tests pass

[tepid nova]

Thinking about the best way to protoype a docker->dagger translation proxy... Wondering if I could implement it as a middleware for the docker engine? Looks like there are some hooks for that: https://github.com/moby/moby/tree/master/api/server/middleware

[obsidian rover]

It seems that we used to forward the credentials from docker login to our engine: https://github.com/dagger/dagger/blob/dcdd9e81c45f0cb807978fe414e9b02547c8155b/core/docs/2ku9n-getting_started.md. Is it still the case (should be), but I can't seem to find where the logic is, in our codebase ?

[tidal spire]

I was looking for this sometime last week. I think it's just this line https://github.com/dagger/dagger/blob/main/engine/engine.go#L101
as in we're not really forwarding credentials but really just using the current auth session

[hasty basin]

related: https://github.com/dagger/dagger/issues/3138

[rancid turret]

@civic yacht: https://github.com/dagger/dagger/pull/3716

[obsidian rover]

You're right, we're loading the credentials of the docker cli: https://github.com/moby/buildkit/commit/e6d91fbeaaab80b51a43384b45a7a7ac550f919e. thanks 🙏.
I think we're still relying on an old version of Buildkit, so the docker login still works as-is

[obsidian rover]

A doc is on-the-way, just realized that we already manage this issue 😇

[still garnet]

here's the latest on remote engine/client sessions: https://github.com/dagger/dagger/pull/3671#issuecomment-1305943293 - this is shaping up to be a pretty hefty PR, might make sense to jump in a call and sync up on it at some point. i'll be in-and-out today though, gotta clean all the 🍂 from the patio. (cc @civic yacht @wet mason )

[civic yacht]

Awesome, I gotta focus today on the engine image stuff for the release but looking forward to catching up on all that (sometime in the next day or two), it's extremely exciting that it's even in the cards already!

[tepid nova]

IS anyone relying on the "0.3.0-alpha.1" milestone? https://github.com/dagger/dagger/milestone/9

If not, I will delete for clarity

[wet mason]

🔥

[tepid nova]

amazing

Could I request some eyeballs on the newly cleaned up 0.3 CLI design issue? https://github.com/dagger/dagger/issues/3347

(thanks to @wild zephyr for the nudge)

@wet mason @still garnet @civic yacht do you use this milestone at the moment? "0.3.0" https://github.com/dagger/dagger/milestone/8

[civic yacht]

I had been defaulting to it previously since I thought it meant "the official non-alpha release" but I guess our approach has changed since then. So I don't think we need it anymore?

[tepid nova]

From a launch point of view it's not needed. So it all depends if it helps you organize and prioritize your work 🙂

My thinking, for now was to have a milestone called either "Engine 0.4" or "Engine 0.3.x" to track roughly what is planned next. But not a lot of opinions on the details there, I defer to @wet mason and @cosmic cove on the tooling bikeshedding

It's basically a backlog thing

[civic yacht]

0.3.x makes sense to me. Anything that is longer term (someday) can just be labelled w/ engine but not put in a milestone. And when we decide to do a 0.4 then we can create that milestone, etc.

[still garnet]

+1, I'm not dependent on any milestone atm so feel free to reorganize in whatever way makes sense

[tepid nova]

Ok cool

Note, there is a separate milestone called "Engine GraphQL release" which tracks specifically what is needed to publicly release the GraphQL API. On the launch side we are using that milestone as a dependency

[tawny flicker]

Hey, anyone has encountered this?: https://github.com/dagger/dagger/actions/runs/3413603328/jobs/5680511185#step:4:183

Can't run linter goanalysis_metalinter: buildir: failed to load package xxx: could not load export data: no export data for xxx_go-package_xxx

[hasty basin]

Boosting this one https://github.com/dagger/dagger/issues/3710 @still garnet @wet mason @civic yacht Export() after WithEntrypoint()

[still garnet]

replied: https://github.com/dagger/dagger/issues/3710#issuecomment-1306144326

[tawny flicker]

oh yeah, great source of confusion

[ancient kettle]

@civic yacht @still garnet Is it possible to Container.Export a tar file into a new Directory? I'm guessing it probably isn't... and I'll likely need to do what we're currently doing in core.#Export (which is export the tar to the host, then reload it using client.Host().Directory(...).

[still garnet]

yeah, it's not possible to do that without first writing it to the host

[ancient kettle]

Cool, I appreciate verification.

[tepid nova]

There is a draft API call for that I believe 🙂 But we decided to delay implementation for practical reasons

[ancient kettle]

Well, I could definitely use it when it's ready. 🙂 Until then, I should be fine.

[wet mason]

I think you need to edit util.go RepositoryGoCodeOnly to add **/.ts.tmpl files

[ancient kettle]

I have an interesting panic:

package main

import (
    "context"
    "fmt"
    "dagger.io/dagger"
)

func main() {
    ctx := context.Background()
    d, err := dagger.Connect(ctx)
    dockerfilepath := "mydockerfile"
    buildcontext := d.Directory().WithNewFile(dockerfilepath, dagger.DirectoryWithNewFileOpts{Contents: "FROM scratch"})
    build := d.Container().Build(buildcontext, dagger.ContainerBuildOpts{Dockerfile: dockerfilepath})
    buildid, err := build.ID(ctx)
    if err != nil {
        panic(err)
    }
    fmt.Println(buildid)
}

$ go run ./cmd/dagger/main.go
panic: input:1: container.build runtime error: invalid memory address or nil pointer dereference

Please visit https://dagger.io/help#go for troubleshooting guidance.

goroutine 1 [running]:
main.main()
    /Users/joel/src/dagger/dagger-cue/cmd/dagger/main.go:41 +0x140

Seems like Container.Build isn't dealing with scratch nicely. Maybe the protobuf -> json encode really doesn't like the nil?

[tepid nova]

Call for feedback on cleaned up / edited issue for helper binary: https://github.com/dagger/dagger/issues/3653

[tawny flicker]

Thanks, that was it

[ancient kettle]

Any thoughts on this, @civic yacht @still garnet @wet mason?

[tawny flicker]

The CI on my PR doesn't trigger except for docs and website

I'll rebase, just to check

The rebase fixed it

[still garnet]

yeah, I've run into a few of these, they all have to do with 'scratch', some of them come from buildkit itself

there might be more info in the dagger-buildkitd container logs

[civic yacht]

Like @still garnet said there's a chance this is buildkitd. I've fixed 2 bugs upstream that were related to scratch+nil in the last month-ish, apparently some of the other maintainers have pushed even more similar fixes recently (not sure why this is such a thing all of a sudden). But this could easily be our code too, if you can do a recover() in this code you could see where the panic is happening: https://github.com/sipsma/dagger/blob/7544c0e3292d9fcd2de618804e47e2ef4545d186/core/container.go#L261-L261

[tepid nova]

Might be a sign that the buildkit ecosystem is picking up finally!

• dagger gaining steam
• earthly definitely getting some extra attention since dagger launched (based on star history)
• depot.dev: first buildkit hosting service
• docker itself making a comeback

Maybe it’s adding up 🙂

[civic yacht]

True, there's lots of activity and fun stuff going on upstream these days!

[tepid nova]

Oh my, I'm having second thoughts on the CLI/helper thing... I hate when that happens 😦

[cosmic cove]

@tepid nova @hasty basin @tidal spire After the livestream today, can you takes a look at this issue for where examples should live? I'd like to make sure that all the directories are clear before the Python launch - https://github.com/dagger/dagger/issues/3446

[bronze hollow]

Does the Go SDK support CreateSecret yet?

[still garnet]

no, but there's a rough plan coming into shape for passing a secret provider to dagger.Connect

[tidal spire]

Will that be in the form of an interface? I haven't been following this thread closely enough

[still garnet]

yeah. none of this is officially planned (no issue yet), just something that gets a lot easier with https://github.com/dagger/dagger/pull/3671

[ancient kettle]

Thanks @still garnet! I'll check the dagger-buildkitd logs to see if I can gain any insight. And I'll throw that recover in if that doesn't give me enough insight, @civic yacht.

[tawny flicker]

What is this second thought?

[ancient kettle]

@still garnet @civic yacht I'm getting behavior I'm not expecting trying to add and test functionality to func (dir *Directory) Without(ctx context.Context, path string) (*Directory, error). It appears that my changes aren't running. Do I need to do anything to compile that code and get it running in the engine?

I'm running the test using go test -v -count=1 -run TestDirectoryWithoutDirectory $(pwd)/core/integration/

[still garnet]

@ancient kettle hmm try mage engine:dev

i think this is different now that https://github.com/dagger/dagger/pull/3647 is merged

[civic yacht]

^^ Did you update to the latest commit already?

[ancient kettle]

I'm currently on

Merge pull request #3724 from sipsma/rm-embedded

Remove embedded engineconn from Go SDK

So, I think so.

[rancid turret]

Any idea for this error?

#1 resolve image config for docker.io/library/python:3.10-alpine
Error: input:1: container.from error getting credentials - err: signal: killed, out: ``

Please visit https://dagger.io/help#go for troubleshooting guidance.
#1 ERROR: error getting credentials - err: signal: killed, out: ``                                                                                                                                       
------
 > resolve image config for docker.io/library/python:3.10-alpine:
------

[ancient kettle]

Maybe I'll go back one commit?

[civic yacht]

Ah okay yeah, that's my bad, I was planning on writing out the dev docs today but I forgot there's others actively working on the engine, should have done an announcement in the meantime. Alex is correct, you can run mage engine:dev whenever you make a change to the engine, it will print out an env var that you can export to use your locally built engine for any commands

[ancient kettle]

🙏🏻 That'll work great.

[rancid turret]

Even on main... trying full cache reset.

[still garnet]

sounds like your docker credential helper is getting killed for some reason? maybe there's something weird in ~/.docker/config.json

[rancid turret]

I've been running tasks all day, it's not that.

Full cache reset, still same issue.

Should I reboot machine? 🤣

[still garnet]

maybe. OOM killer? 😛

[rancid turret]

Have I reached a rate limit or something?

[mellow bolt]

did you reboot docker ? 🤷

[rancid turret]

Am I going to be punished for still using docker desktop? 😛

[tidal spire]

I had some weird stuff happening this morning and a docker reboot fixed it lol

[rancid turret]

Ok, after rebooting docker desktop I get a "Login rejected" error.

[mellow bolt]

f****

[still garnet]

progress 👍

[tidal spire]

successfully failed

[rancid turret]

Successful login in docker desktop but still failing in mage. Gonna try docker login.

[ancient kettle]

Thank you @still garnet + @civic yacht. I got it working!

[rancid turret]

Man, every time I try to login I get sent to the hub.docker.com page with a "You've been signed out"

I even created a new token.

Hmmm: ""access is forbidden with a JWT issued from a personal access token"

Ok, success logging in via CLI, still same error. How does credentials get passed on to buildkit?

[still garnet]

goes through this, which uses your docker credential helper: https://github.com/dagger/dagger/blob/d0e08e48a909fc14647b8be5047597f8243d48a4/engine/engine.go#L102

[rancid turret]

Hmmm... login succeeds with index.docker.io but not docker.io.

[still garnet]

deeper link: https://github.com/moby/buildkit/blob/164c92aebe3863f74f52222f6fffebd454494c04/session/auth/authprovider/authprovider.go

[rancid turret]

I can pull that image locally, but not from go sdk. Any idea?

[civic yacht]

Is this on your PR? I can try to reproduce it

If this is happening in a mage step then there's also the dagger-in-dagger complication

[rancid turret]

No, even on main.

Am I doing docker hub login wrong?

[civic yacht]

What's the command you're running?

[rancid turret]

mage sdk:python:test... it's failing base when pulling the python image.

Same thing with go:

#1 resolve image config for docker.io/library/golang:1.19-alpine
Error: input:1: container.from error getting credentials - err: signal: killed, out: ``

Please visit https://dagger.io/help#go for troubleshooting guidance.
#1 ERROR: error getting credentials - err: signal: killed, out: ``                                                                                                                                       
------
 > resolve image config for docker.io/library/golang:1.19-alpine:
------

[civic yacht]

Huh yeah I can reproduce it too... at least on macos. Let me see if it also happens on linux

doesn't happen on linux...

(another reason we need to setup mac os runners in our ci)

I'll keep digging

[ancient kettle]

@tepid nova @still garnet @civic yacht @wet mason I have a behavioral change (and potential API change discussed) to Directory.withoutDirectory() in this PR: https://github.com/dagger/dagger/pull/3735

I'd appreciate some eyes on it, and any thoughts as well, especially about the API to this change.

[ancient kettle]

@civic yacht Should I expect envvar -> secret code to break in the latest main?

[civic yacht]

No, I believe we have test cases for it that pass too, so unexpected

[ancient kettle]

Ok. I'll double check my tests to make sure that's what happening.

[civic yacht]

Oh! you know what, it actually is possible... the way that we spawn the helper means that all the env vars are set when you call dagger.Connect now. That would have always been the case in other SDKs so it's probably the right thing, but it's also true in Go now...

[civic yacht]

@rancid turret @ancient kettle truly mystified by that credential error, here's what I found so far: https://github.com/dagger/dagger/issues/3737

I gotta look at other engine related stuff too asap so temporarily putting it to the side, but if anyone else has time to look into it please feel free

[tepid nova]

@wet mason @wild zephyr idea for the problem you mentioned of multiple releases being messy in github. Maybe we could (in github) only expose “group releases” of the latest engine+all sdks? With one tarball for each artifact in the release. The bundled release would be versioned after the engine.

So for example we could cut right away a “0.3.0” release which would include:

• engine 0.3.0
• go-sdk 0.4.0

It’s not perfect because not every sdk release would be in a github release, but that’s ok since github releases are not the source of truth anyway: just a convenience for people visiting the repo as a distribution channel

[still garnet]

@civic yacht just to confirm: do you see https://github.com/dagger/dagger/issues/3739 replacing util.WithDevImage and/or turning it into a no-op if it sees DAGGER_HOST is already set?

[civic yacht]

I was imagining we get rid of it from all that code entirely and just rely on DAGGER_HOST. Then we have a separate command (with separate go.mod) that will setup dev dagger and then run whatever command you want with DAGGER_HOST set appropriately

[still garnet]

great, sounds good. I have the latter part done, just need to remove this bit then 👍

there was one wrinkle: rather than relying on 'latest stable SDK' I went with a git submodule (😵‍💫) so we can depend on main instead. since we're already depending on unreleased features (e.g. dagger-in-dagger)

so now we have a lovely blend of Go and Git submodules 😅 but it works

[civic yacht]

Oh interesting, I would have thought that even if we use a go.mod we could bump it to be something besides a tagged release (like a specific commit) when needed but i'm probably forgetting how that works

[still garnet]

I can give that a try too 👍 honestly just avoided that since a lot of things have to go right for it to work

[civic yacht]

Yeah totally, git submodules may somehow be the lesser of two headaches here 😞

[still garnet]

yea, I figure we can always just remove it if/when stable becomes actually stable enough, and it's pretty easy to reason about bumping to commits and/or tagged releases (just git checkout the submodule and commit it)

[still garnet]

@civic yacht a simple go get dagger.io/dagger@main works fine. 👍 the only gotcha is that updating these files is trickier than bumping a submodule, since you need to move them alongside the code to run go get ...; go mod tidy and then move them back into their separate folder after. but that can be scripted. (they're tracked in a separate folder and copied out just-in-time for the mage re-exec'ing)

i'll go with this + a script since I never want to wonder what people mean when they say "submodule" 😛

also it's really annoying having the git submodule results show up when grepping

[strong coral]

I've looked at the published SDKs and python is gibberish enough to me that I don't understand what it's actually doing. Is there a psudo-code explanation of how codegen gets data and turns it into code?

[tepid nova]

Welcome to the frontier 🙂

[strong coral]

To soon?

Hmm, yes. Mage build doesn't work on Windows

[tepid nova]

No it's a great question to ask, would love to help you get going prototyping a new SDK. Just want to set expectations that it's still rough at the moment. But definitely doable and something we're interested in supporting.

[strong coral]

Actually, the playground is probably a good place to start

I just need something that generates GQL queries, right?

[tepid nova]

@strong coral to clarity your goal is to contribute a new SDK for .net?

[strong coral]

Likely PowerShell. Not sure yet if I'd do that through .Net or just directly in PowerShell.
.Net is two birds, one stone, but way more work.

[tepid nova]

It depends whether you want to:

A) contribute a SDK with the goal of having feature parity with other official SDKs (Go etc)
B) develop a custom client library/tool that makes it easier for you to make certain graphql queries, but is domain-specific and not meant to be used by all developers targeting developers in that language

[strong coral]

B>A for me at the moment

but all of the SDK implementations seem light enough and I assume would be more flexible as you evolved the engine

[tepid nova]

Ok, that's an easier first step, and yes starting with the playground + a basic functional graphql client in your language, is the way to go

[strong coral]

Yeah I think that's an appropriate MVP

[tepid nova]

That way you can ignore the codegen part (additional work for option A), and focus on getting a working session. There's two parts to that:

1. Dagger-specific bootstrap to establish a connection to the graphql server
2. Regular graphql client to make the queries

Part 1 is where you will need some handholding, as the bootstrap code is 1) not well documented and 2) changing fast

I would look at Python as the reference (not Go which is a special case)

[wet mason]

Saw the PR ... I don't have a better solution in mind yet, but I'm concerned about the layers of complexity 😐

The only other potential alternative I have in mind (I think I mentioned that yesterday) is to have a way for our CI code to use the embedded driver somehow, to avoid all of this

[civic yacht]

I think embedded would not cover us for all that much longer though since it basically just means that the helper binary (now called dagger-engine-session) part of provisioning can be skipped, but it wouldn't cover all the other stuff in the actual engine image. Currently there's not much in there (just buildkitd and it's associated binaries like qemu+runc). But once we start doing more and more with that it's going to become necessary to rebuild that full image and all the stuff inside and embedded won't work anymore.

Haven't looked at PR yet but hopefully the complexity can be isolated to just this bootstrap aspect and completely modularized from the rest of the automation, which can be nice and simple still

That's what I think the wrapper idea enables

[ancient kettle]

@civic yacht @still garnet So, I've narrowed down where that FROM scratch Dockerfile is failing.

https://github.com/sipsma/dagger/blob/7544c0e3292d9fcd2de618804e47e2ef4545d186/core/container.go#L275

bkref.ToState() is panicking.

I'll keep digging, but wanted to give you a bit of context.

[wet mason]

Yeah, first we should decide if we want to optimize for speed or for "test correctness"

If the latter -- bootstrap should probably only build the image, let the SDK provision (need to be able to pass docker socket though). Would remove one layer of the onion (d-in-d)

That being said, we should find a way to "stash" that stuff (bootstrap) somewhere

[wet mason]

I'm trying but I have no idea of what's going on

@civic yacht Looks like it's in the "handoff" between versioned and bootstrapped engine, since the line that fails is always pulling golang (first thing we do in the inner loop)

[civic yacht]

bkref ToState is panicking

Yeah first we should decide if we want

[obsidian rover]

@civic yacht, I can resume my work on https://github.com/dagger/dagger/issues/3225 if you feel that the priority has bumped (tomorrow). I paused it for other priorities, but it seems that it became more import lately

[civic yacht]

Well I can't say whether it's higher priority than the other stuff you're working on, but it's definitely pretty important IMO, even more so than previously. There's a lot of subtle details that can unexpectedly be different between linux+macos (and windows, which we should also add testing for), and we want to make sure we get those details right in each of our SDKs. Until we have automated testing we have to rely on people manually testing, and only those who actually have macos available to them.

[obsidian rover]

Ok, bumping it on my priority list. I still had it under my radar, but was moving it after some other stuff 🙏

[tepid nova]

@obsidian rover LANG=en-US nitpick: you probably meant "on my radar". "Under the radar" means "invisible, unnoticed" 🙂

[obsidian rover]

yes, "on my radar", sorry 😇🙏

[civic yacht]

FWIW I didn't even notice that 🙂

[still garnet]

@civic yacht @wet mason @tepid nova just to sync on remote-engine/client-sessions/etc. work (https://github.com/dagger/dagger/pull/3671) in light of my vacation next week - I'm guessing we'll have enough to focus on already with the Python SDK launch + whatever things come up afterwards, so I've been just tending to the PR to keep it from falling too far behind. I'm good with either a) pausing it while I'm out, b) letting y'all scrap it for parts if/when the need comes up, and/or c) chatting about it tomorrow or Friday if someone wants to carry the torch. I haven't been too loud about it since we've got enough distractions 🙂

[wet mason]

Let's chat about it this week ... definitely don't want to have that PR fall behind

[civic yacht]

^ +1 sorry I haven't had time to catch up on it yet, chatting tomorrow or friday sounds great

[still garnet]

no worries at all, this was a side quest 😆 i'll send an invite

[tepid nova]

https://tenor.com/view/the-legend-of-zelda-nintendo-snes-alttp-a-link-to-the-past-gif-17194667

[strong coral]

What does the bootstrap code do? Is that what is being put in dagger-engine-session?

[tepid nova]

It opens a session with the dagger engine, possibly installing it on the fly. Yes that’s what dagger-engine-session does, it’s in a binary that you can exec to save you time in developing a custom client.

[strong coral]

How is that different than cload dev?

[tepid nova]

it’s basically cloak dev without the user having to install anything

[strong coral]

nice

Is the graphql schema static per build or is it dynamic based on host configuration?

[tepid nova]

Static per build

Not 100% sure if that remains the case once we ship extensions, cc @wet mason @civic yacht

[obsidian rover]

@civic yacht, the native macos runner is working/successfully running our integration tests against a Docker Desktop: https://github.com/grouville/dagger/actions/runs/3437568316.
Due to the power of the VM provided (native Github macos-latest runner), it is quite long (1h) per run, on what trigger would you like it to be set ?

[obsidian rover]

https://github.com/dagger/dagger/pull/3774

[wet mason]

@civic yacht Woops: https://github.com/dagger/dagger/pull/3779

@stray heron ended up not doing self hosted runners for now (need more work to make it happen)

I reworked the PR though to keep some of the changes needed for self hosted and limited the usage of big runners just for engine:test: https://github.com/dagger/dagger/pull/3722

[civic yacht]

Commented on your PR https://github.com/dagger/dagger/pull/3774#issuecomment-1310656428

[civic yacht]

Yeah that'll change with extensions, but the current idea is that you obtain those schemas the same way you obtain the core schema. All subject to change, etc.

[ancient kettle]

@civic yacht I've updated my local dagger-engine to latest main, but I'm still getting the credential errors. Is there anything I need to do?

[civic yacht]

The fix was to the Go SDK rather than the engine, did you update that code too?

[ancient kettle]

Ah. I'll do that and let you know.

I rebuilt dagger-cue and it works! Thanks, @civic yacht

[ancient kettle]

$ yarn test
yarn run v1.22.19
$ bats --jobs 4 --print-output-on-failure --verbose-run .
./plan.bats
 ✓ plan/do: action flags help output
 ✓ plan/do: action sanity checks
 ✓ plan/do: don't run unspecified tasks
 ✓ plan/do: nice error message for 0.1.0 projects
 ✓ plan/do: missing packages suggests project update
 ✓ plan/do: check flags
 ✓ plan/hello
 ✓ plan/client/filesystem/read: fs/usage
 ✓ plan/client/filesystem/read: fs/not_exists
 ✓ plan/client/filesystem/read: fs/invalid_fs_input
 ✓ plan/client/filesystem/read: fs/invalid_fs_type
 ✓ plan/client/filesystem/read: fs/relative
 ✓ plan/client/filesystem/read: fs/multiple
 ✓ plan/client/filesystem/read: fs/dynamic
 ✓ plan/client/filesystem/read: file
 ✓ plan/client/filesystem/write: fs
 ✓ plan/client/filesystem/write: files
 ✓ plan/client/filesystem/write: multiple
 ✓ plan/client/filesystem: update
 ✓ plan/client/env usage
 ✓ plan/client/env optional set
 ✓ plan/client/env concrete
 ✓ plan/client/commands
 ✓ plan/with
 ✓ plan/outputs
 ✓ plan/platform
 ✓ plan/do: invalid BUILDKIT_HOST results in error
 ✓ plan/do: cache
 ✓ plan/validate/concrete
 ✓ plan/validate/undefined
./project.bats
 ✓ project init and update and info
 ✓ project init with template
 ✓ todoapp project with absolute path
./tasks.bats
 ✓ task: #Pull
 ✓ task: #Pull auth
 ✓ task: #ReadFile
 ✓ task: #WriteFile
 ✓ task: #WriteFile failure
 ✓ task: #Exec args
 ✓ task: #Exec env
 ✓ task: #Exec env secret
 ✓ task: #Exec mount cache
 ✓ task: #Exec mount fs
 ✓ task: #Exec mount secret
 ✓ task: #Exec mount tmp
 ✓ task: #Exec mount file
 ✓ task: #Exec workdir
 ✓ task: #Copy exec
 ✓ task: #Copy file
 ✓ task: #Copy exec invalid
 ✓ task: #Mkdir
 ✓ task: #Mkdir parents
 ✓ task: #Dockerfile
 ✓ task: #Dockerfile inlined
 ✓ task: #Dockerfile inlined heredoc
 ✓ task: #Dockerfile path
 ✓ task: #Scratch
 ✓ task: #Scratch writefile
 ✓ task: #Subdir
 ✓ task: #Subdir invalid path
 ✓ task: #Subdir invalid exec
 ✓ task: #GitPull
 ✓ task: #GitPull invalid
 ✓ task: #GitPull bad remote
 ✓ task: #GitPull bad ref
 ✓ task: #HTTPFetch
 ✓ task: #HTTPFetch not exist
 ✓ task: #DecodeSecret
 ✓ task: #NewSecret
 ✓ task: #TrimSecret
 ✓ task: #Source
 ✓ task: #Source include exclude
 ✓ task: #Source relative
 ✓ task: #Source invalid path
 ✓ task: #Source not exist
 ✓ task: #Diff
 ✓ task: #Export
 ✓ task: #Rm

78 tests, 0 failures

✨  Done in 56.47s.

[ancient kettle]

I've disabled a number of tests that exercise currently unavailable functionality. That said, it feels good to have this much done!

[civic yacht]

Fun fact: the engine image released alongside the python SDK by coincidence got a SHA starting with 666 😈 https://github.com/dagger/dagger/pkgs/container/engine/49839709?tag=v0.3.4

[ancient kettle]

@still garnet Addressed your comments: https://github.com/dagger/dagger/pull/3735

[still garnet]

@ancient kettle approved!

[ancient kettle]

@wet mason @still garnet @civic yacht I had some flakiness with engine with -race:
https://github.com/dagger/dagger/actions/runs/3439384759/attempts/1
vs
https://github.com/dagger/dagger/actions/runs/3439384759/jobs/5738662332

[still garnet]

looks like a good old fashioned timeout

hard to tell which test though

[civic yacht]

Oh I got that in a PR a few days ago, same hang on same test, and added a dump of the buildkit logs to gha to see if it had more info

[civic yacht]

It's TestPlatformEmulatedExecAndPush I believe and it seems to be hanging on the part where you export to the locally running registry

That's my guess because the last thing in the buildkitd logs is: "> creating tuiqcoecgb7wx1y5fzt384rc4 [/dev/.buildkit_qemu_emulator /bin/sh -c CGO_ENABLED=0 go build -o /_shim -ldflags '-s -d -w' .]" span="[build 6/6] RUN CGO_ENABLED=0 go build -o /_shim -ldflags '-s -d -w' ."
And the stack trace of goroutines when the test times out shows it stuck on the registry goroutine

[still garnet]

I see TestContainerMultiPlatformExport in the stack

but it is an Export call yeah (there's also a goroutine calling ExitCode but I think that's the one we always background for the lifetime of the registry?)

oh dang I guess we don't get the engine stack in these dumps anymore 😢

also seems likely this could be only loosely related to the actual test that fails, could be anything that starts a registry

btw, i've been tempted to switch these tests to https://github.com/google/go-containerregistry/tree/main/pkg/registry - but it's been kind of interesting to do it with dagger, so haven't bothered

[civic yacht]

Finally found the one that happened the other day, it actually is the same hang on the same test case (I misremembered which one, but yeah it's TestContainerMultiPlatformExport like you said): https://github.com/dagger/dagger/actions/runs/3416253271/jobs/5686204381

Could be coincidence, but suspicious

[still garnet]

and that one's without -race, interesting

wonder if we should have an hourly trigger just to suss out flakiness like this (more data to confirm if it's just one test)

[ancient kettle]

Stepping out to do a couple of errands. Let me know if I can help in any way.

[civic yacht]

The other interesting thing is that it seems like it might be both were blocked on building the shim. Last progress output from one 3 days ago is:

#33 [build 6/6] RUN CGO_ENABLED=0 go build -o /_shim -ldflags '-s -d -w' .

It never completes.
In the newer one that also is one of the last progress outputs and never completes. And in the buildkitd logs you can see the last thing is:

creating tuiqcoecgb7wx1y5fzt384rc4 [/dev/.buildkit_qemu_emulator /bin/sh -c CGO_ENABLED=0 go build -o /_shim -ldflags '-s -d -w' .]" span="[build 6/6] RUN CGO_ENABLED=0 go build -o /_shim -ldflags '-s -d -w' ."

Hmm....

[civic yacht]

Just made an issue for it now, I'll add dmesg output to GHA test steps quickly just to see if there's anything of use there (doesn't hurt to have that anyways): https://github.com/dagger/dagger/issues/3784

[tawny flicker]

off-topic: incredible, Go might get a standard structured logger: https://pkg.go.dev/golang.org/x/exp/slog

[still garnet]

hopping in dev-audio for client sessions sync @wet mason @civic yacht @tepid nova

[wild zephyr]

👋 just came across a very recent git bug (https://lore.kernel.org/git/[e-mail]/T/) that basically makes goreleaser fails when fetching the contents of the tag description. This only happens when tags are signed, which is something that we don't usually do since we create the tags from github itself. Spent a good amount of time tracking this one. Also, funny quote from the issue (img).

If you get an "Out of memory" error when running goreleaser locally it's because of that

[tepid nova]

Hi there! Here it is: https://github.com/dagger/dagger/tree/main/sdk/python

There is a #python-sdk-dev🐍 channel if you want to dig deeper

Yup, you got it 🙂

Ha ha, meet @strong coral who is thinking along similar lines, but for powershell 🙂

The short answer is: it's possible to contribute a SDK, but it's a non-trivial engineering effort and you would have to work closely with the core developers (who are happy to help you, right here on discord, it's more about your own ability to commit the necessary time and effort)

There's a good intermediary step which is to write a custom client targeting the Engine API directly

Then you can generalize the client so that it eventually becomes a full blown SDK.

That second part is actually the hardest because it involves code generation

(All our SDKs are fully generated from the API)

To be more specific:

• The Dagger Engine has a GraphQL API
• You can target this GraphQL API yourself with a regular graphql client in any language + some dagger-specific bootstrap code
• Each SDK includes a generated client for the GraphQL API

@gleaming portal not launched / announced yet, but here's the best way to explore the API 🙂 https://play.dagger.cloud

🤫

one and the same

engine API = graphql API

if you try that playground, you can actually run your pipeline straight from the browser, we run an engine for you. It's pretty fun

@gleaming portal my pleasure, happy to help any time. We can also get on a call with some of the devs and help you get started

[strong coral]

I got a good bit working today. Hit a couple of road blocks I bet you could help with.

I used https://github.com/Husqvik/GraphQlClientGenerator to generate the types from the graphic schema.

[wet mason]

@civic yacht if I wanted to publish a dummy engine to test things out ... can I use call engine:publish randomtag? is that safe?

[civic yacht]

Oh I skipped actually codifying that right now, but yeah we should add a separate target for pushing to your own repo. The way to do it now is to just change ghcr.io/dagger/engine to <whatever else> in the actual code (internal/mage/engine.go)

Which is fine, but annoying relative to having a separate target

[wet mason]

👍

Oh btw, I reverted the self hosted runner changes, need more time to do a proper set up. I converted the PR to add the bits required for self hosted in the future (don't mess with /usr/local/bin) and also reduced the usage of large instances (we don't need them in most cases): https://github.com/dagger/dagger/pull/3722

[civic yacht]

shipit, the readthedocs failure has happened to me before, passed on a re-run

[wet mason]

@civic yacht https://github.com/dagger/dagger/pull/3786

It's a bit hacky, does the job though

[civic yacht]

Awesome!! I'm trying something quickly with the engine stuff we talked about before rn, I will look in a few

[civic yacht]

@still garnet @wet mason @tepid nova I couldn't get the idea I tried but failed to articulate earlier out of my head, got it working here though which helped clarify it a bit more: https://github.com/dagger/dagger/pull/3787

That PR successfully runs test / engine via dagger-in-dagger, including the local dirs tests. I had to comment out extension tests for now but they should be easy to fix too, I just didn't bother to update that part of the codebase yet. The other SDK tests fail for the same reason, they are easy to fix I think.

I list the pros/cons in there, let me know what you think. The pros seems really huge, a lot of problems seem to go away, so I think there may be something here? But I also need other brains to double check I'm not just tired and missing something obvious...

[still garnet]

ooh nice, I think I grok it

so every level of nesting starts its own router + local buildkit client/session, and they just share the lower-level buildkit host instead

[civic yacht]

Yes exactly, but that just results in the nested client to do the exact same thing as the non-nested ones

And in the future I think we can replace "share the lower-level buildkit" with "share the lower-level dagger-runner" or something, since we probably don't want to directly expose APIs we don't directly control in the long run.

But we wanted to wrap buildkitd anyways, so that might fit in perfectly

I also have some side-thoughts about whether playground could be implemented as dagger-in-dagger using this approach...

[tawny flicker]

I'm finishing the NodeJS code generation, but I'd be happy to help for C#. I've done a few years of it.
The biggest work where I wouldn't be as fresh would be about the graphql query builder that you would have to create with C#

[wet mason]

Commented -- need more time to think it through, but it's super interesting

[tepid nova]

so I think that’s how I thought it worked in the first place 😅

either that or there’s a subtlety I’m missing

[wet mason]

I'm tired, I'm going to call it a day 🙂 I think that's going to be the main engine topic of next week -- figuring out the engine/session/etc architecture, incremental steps, etc. It's becoming the elephant in the room by the day

[tepid nova]

https://tenor.com/view/baby-elephant-sneezing-dumbo-gif-14311796

a cute elephant though

[wet mason]

unrelated topic, also to figure out, is sockets. Added some thoughts here: https://github.com/dagger/dagger/pull/3691#issuecomment-1311145961

It's becoming painful -- can't open PRs from our own pipelines because we can't forward the ssh agent. And we can't run the provisioning tests automatically because we can't forward the docker socket inside dagger

[wet mason]

For the latter, we can only run provisioning tests manually on our laptops without dagger. Which we are doing on every SDK release

[wet mason]

https://tenor.com/view/elephant-gif-6131694

[still garnet]

saw that too, gonna take a deeper look soon! i started writing a similar comment, obviously motivated by what i did with bass, i'd be super excited if we landed close to what your comment has so far

[civic yacht]

Thanks, got back, agree it's late and spiritually Friday, looking forward to figuring this out more next week! 🙂

[civic yacht]

It's a very subtle change from before, that's why it was hard to articulate. I think the reason it works out nicely is that it makes the behavior of clients outside dagger and clients inside dagger the same, whereas before there was a very subtle asymmetry (clients outside ultimately connected to a buildkit session, whereas clients inside ultimately connect to a router instance).

[tepid nova]

yeah the symmetry is great

[civic yacht]

Along those lines, that change made me see so much symmetry between shim and engine-session that I am starting to wonder if they should be the same thing, but idk about that yet fully

[wet mason]

Yeah I remember reading through bass and thinking that’s what we have to do for services. Lots of details to figure out but I think it would work out great

[wet mason]

I signed off and came back to say that that statement just hit me 🙂

[tepid nova]

would that make shim… a wrapper? 😀

I mean it already is…

[still garnet]

https://giphy.com/gifs/WI4A2fVnRBiYE

[tepid nova]

but like, other wrapper too

[wet mason]

There’s a lot of symmetry. Not sure what to do with it yet.

What @tepid nova was mentioning (e.g. dagger exec go run … that transparently exposes a DAGGER_HOST) and what the shim is doing, especially with extensions/d-in-d (expose a DAGGER_HOST, run the shimmed stuff) are the same, more or less

[civic yacht]

Yeah exactly, I just deleted the reverse http proxy code from the shim and it worked, didn't have to really add anything new to the engine-session besides reusing the code that already existed there. So it lets us consolidate code and concepts if nothing else, which is always a good thing.

[wet mason]

But the shim does a bit more. And with networking (the other PR, shim proxying stuff) the shim will diverge further.

Or will it? If socket forwarding is handled by the session both locally to the host and in the shim for exec …

[tepid nova]

Hilariously, in my first proposal for 0.3 CLI, there was a dagger exec which was to be the actual shim…

now dagger exec is a client wrapper

[civic yacht]

Yeah exactly!! And also, the other thing the shim does is route stdout/stderr, maybe that ties into the log handling we have needed to figure out too? Maybe?

[tepid nova]

and they may end up being the same thing 😬

[wet mason]

Yeah

😶‍🌫️

[civic yacht]

I sometimes feel like we have been going in circles for a while, but it's actually not a perfect circle, it's more like a long spiral in towards design perfection

[tepid nova]

exactly

rings a bell @wet mason ? 😀

we actively used that spiral metaphor in 2019/2020 to stay motivated through endless iterations of prototypes / feedback / bikeshedding

Makes me very happy that you see it that way too

the straight line is an illusion

[civic yacht]

Oh totally, things have gradually been making more and more sense, even if there's ups and downs. And honestly that's not always the case with every project, quite often grand ideas just disintegrate, so we've definitely hit on something real

https://tenor.com/view/spiral-hypnotic-shape-colors-gif-14476528

mood rn^

[tawny flicker]

The yarn core integration test keeps failing for me. I don't know why: https://github.com/dagger/dagger/actions/runs/3442233685/jobs/5742603176#step:7:1290
Any ideas?

[civic yacht]

Yeah there's not much output to go on there, I think if you update the test case to make its client with dagger.LogOutput(os.Stdout) you should hopefully get more information?

I wouldn't be surprised if the extension just needs updates now that the nodejs sdk has changed though

And if you run into lots of headaches around that, we don't have to maintain those extensions technically. It's nice to since extensions are coming up in the near-enough future, but it's not worth tons of hassle; we are going to need to re-assess and redo a lot of extension stuff anyways.

[tawny flicker]

true

[tawny flicker]

All right, this hypnotic gif is my limit of the day, I'm gonna sleep looking at it ^^
Good night

[strong coral]

This is what GraphQlClientGenerator produced. I haven't figured out how to piece it together to generate a query. https://gist.github.com/cdhunt/e9db9851efbb744ea8b7ed8902846eab

[strong coral]

Working!

[oak sandal]

Hey folks, so I've been using a remote buildkit instance in the past by specifying "BUILDKIT_HOST" variable and running cloak dev. but looks like recent commits broke that behaviour. Can I add a new method provider method here to connect to existing buildkit host? https://github.com/dagger/dagger/blob/main/internal/engine/client.go#L30

[obsidian rover]

https://tenor.com/view/balls-warp-3d-gif-9225226

[strong coral]

Ok, I have it working in a user friendly form

$query = Query {
    Container {
        WithFrom alpine {
            WithExec "apk", "add", "curl" {
                WithExec "curl", "https://wttr.in/" {
                    Stdout {
                        Contents
                    }
                }
            }
        }
    }
}

$data = Invoke-GraphQLQuery -Query $query -Uri "http://localhost:8080/query"

$data.data.container.from.exec.exec.stdout.contents

https://github.com/cdhunt/dagger/tree/sdk/powershell/sdk/powershell

[hasty basin]

Woah! 🤯 Ah! I was wondering what you'd call it: C#, dotnet, Powershell SDK.

[strong coral]

If you run dotnet publish on that folder it will generate the C# types. It could go a lot of directions for making a friendly C# interface around the generated source.

[hasty basin]

@strong coral would you be available next week to show this on the Community Call?

[strong coral]

Yeah, should be available

[tepid nova]

@gleaming portal for now it’s embedded in each SDK. Next week we’re merging a new version of the dagger CLI which will allow you to do that

See https://github.com/dagger/dagger/issues/3347

[tepid nova]

So, there is a helper tool which you can download and run from your SDK, to open a session which you can then connect to. This is what other SDKs do

[tepid nova]

yes 👍

[tepid nova]

Here is the code that uses it in the python sdk: https://github.com/dagger/dagger/blob/main/sdk/python/src/dagger/connectors/docker.py

[hasty basin]

Update: Nic didn't actually need to write out his built binary to the local FS (prob most people don't want to/need to either), so he mounted the Directory from the go build output and copied it into place in his final Container to Publish.

Orginally Nic was surprised that with a Client connection he only had a point in time snapshot of his host workdir. So when he wrote a binary to the host filesystem and wanted to read that artifact back in, he couldn't. If he closed the Client connection and re-opened it, he could then get a new snapshot of the more recent state of the host workdir that had his binary in it. Here are two gists that show that behavior:

Call for src twice, same client. Doesn't refetch host workdir, but uses original snapshot of host workdir without exported build directory. To test ensure you've remove ./build/ before running.
https://gist.github.com/jpadams/71f542bcd774573799729196771f6622

#21 ls -alh build
#0 0.069 ls: build: No such file or directory
#21 ERROR: process "/_shim ls -alh build" did not complete successfully: exit code: 1
------
 > ls -alh build:
#0 0.069 ls: build: No such file or directory
------
input:1: container.from.withMountedDirectory.withWorkdir.withEnvVariable.exec.stdout.contents process "/_shim ls -alh build" did not complete successfully: exit code: 1

Call for client twice. Works. Implicit client close between function calls to build() and list().
https://gist.github.com/jpadams/2a18c70c6e4a555325caf594e21fe031

[rancid turret]

Hey guys 👋 I've been thinking about the logs that come from the engine. Do we support getting those logs in JSON form? If not, can we? I remember seeing somewhere that it's not just logs from buildkit. Is it the API router? Are we sending both at the moment or just buildkit? Use case is to allow for better observability in an SDK. So instead of just streaming everything to screen or a file, would be very interesting to be able to "parse" the logs into user friendly messages. Something like the tty logger from Europa. \cc @civic yacht

[rancid turret]

Ok, just saw https://github.com/dagger/dagger/issues/3587 👍

[lyric jasper]

Local Dev

[civic yacht]

I updated this discussion from a while back with a synthesis what we've been talking about in terms of engine architecture, including the most recent discussions end of last week: https://github.com/dagger/dagger/discussions/3280

Nothing revolutionary if familiar with the past discussions, small differences are: using the name "session router" for the local binary, expanding its possible future scope a bit (could also be used to distribute work to multiple backend runners in the future) and using DAGGER_RUNNER_HOST instead of DAGGER_HOST.

It's not complete at all since it can really encompass so much, just did a first pass this morning. Hoping to use it as an anchor for discussions we were planning to have this week. Next step for me is to go take a look at the CLI PR from @wild zephyr and related issues now to see how this all fits together in the details. cc @wet mason @tepid nova

[tepid nova]

I was just thinking about that over the weekend, thanks for the ping. Will take a look today

[wild zephyr]

Thx Erik, will take a look today. CLI PR is not yet finished, will wrap it up in a few hours. Should be ready for you to 👀 EOD today

[tepid nova]

FYI @wet mason @obsidian rover I'm opening a separate issue about the "mount unix socket", starting with @wet mason 's API proposal. Looks like we can solve 2 user problems at once: ssh forwarding + docker engine access

https://github.com/dagger/dagger/issues/3850

[tepid nova]

@wet mason maybe we should have an overarching "improve networking" issue similar to your "improve logging"

(observing the different threads related to that this morning)

[wet mason]

@tepid nova Would like your opinion on https://github.com/dagger/dagger/pull/3691#issuecomment-1311145961

I raised the question: does it make sense to have container-to-container networking in anything other than services (e.g. regular Execs):

Regular Execs are:

• short lived
• eventual (when do you connect to the socket? might be right away, might be in 10 mins)
• cached (you might never be able to connect if the Exec is cached)

See the startRegistry we use internally for test -- we do weird hacks with random env variable for cache busting, go-routines to make it long-lived, for loop shell coordination to make it consistent

I believe host-to-container and container-container networking is relevant for services only

[tepid nova]

Seems reasonable to support outbound traffic for Exec, but not inbound maybe? Knowing that if a user wants it badly enough, they'll find a way to work around the limitation (reverse connect, something)

[wet mason]

I believe so yes

[tepid nova]

OK, I moved the discussion to the issue and shared some thoughts

[strong coral]

I'm struggling to use dagger-engine-session. It either blocks the shell or shuts down after a couple of seconds.

I assume shut down is triggered by

    go func() {
        io.Copy(io.Discard, os.Stdin)
        l.Close()
    }()

[ancient kettle]

@wet mason @civic yacht Is there any way to force Container.EnvVariables to execute?

package main

import (
    "context"
    "fmt"
    "os"

    "dagger.io/dagger"
)

func main() {
    ctx := context.Background()
    fmt.Println("Connecting")
    d, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stderr))
    if err != nil {
        panic(err)
    }

    fmt.Println("Getting EnvVariables from nginx:1.23.2")
    nginx := d.Container().From("nginx:1.23.2")

    vars, err := nginx.EnvVariables(ctx)

    fmt.Println("Printing ", len(vars), "environment variables")
    for _, env := range vars {
        name, err := env.Name(ctx)
        if err != nil {
            panic(err)
        }
        val, err := env.Value(ctx)
        if err != nil {
            panic(err)
        }
        fmt.Println(name, "=", val)
    }
}

Connecting
Getting EnvVariables from nginx:1.23.2
Printing 0 environment variables

[wet mason]

did err return an error?

[ancient kettle]

Yes: input:1: Field "envVariables" of type "[EnvVariable!]!" must have a sub selection.

[wet mason]

it should have executed given that it takes a ctx

[ancient kettle]

Maybe something weird is happening in the query builder for that one?

[wet mason]

Yeah, returning a lists of objects doesn't work ...

I don't know if it's fixable or if EnvVariables should return a list of strings instead

/cc @civic yacht

[ancient kettle]

Yeah, that makes sense.

[wet mason]

I think EnvVariables is the only one in the API

Could you log an issue please?

[ancient kettle]

Yup!

https://github.com/dagger/dagger/issues/3860

[rancid turret]

That's a duplicate... let me find it

[wet mason]

Happens to me all the time ... I file an issue and then find out Helder opened the same days before me 🙂

[ancient kettle]

He’s on top of it.

[strong coral]

Is engine-session supposed to write buildkit output to stderr?

[civic yacht]

Yes it will always write the logs to stderr, the SDK can decide whether it should forward those logs to the caller or just discard them (currently configurable in the SDKs via a LogOutput option to dagger.Connect)

[tepid nova]

@wet mason @civic yacht did we release the version of the Go SDK that doesn't require go mod edit yet?

• If not, can we?
• If yes: docs need to be updated

[civic yacht]

We didn't yet, didn't want to change too much at once as part of the python release. We can release it though as part of the upcoming updates @wet mason listed out in some other thread on discord

[tepid nova]

Wouldn't it be a Go-only release though?

ie something that wouldn't affect other SDKs or the engine

(but maybe more complicated than that because of the engine/session helper dependency)

As long as it's on your radar 👍

[civic yacht]

Yeah I think we probably could in theory do the release independently even given the new session binary, it just felt like a lot in the midst of everything else. It's definitely not forgotten, I'm excited to delete lines of documentation 🙂

[wet mason]

Yeah, just because too much was going on at the same time

[wild zephyr]

CLI PR is ready for 👀 whenever you have a sec @civic yacht @tepid nova @stray heron . I'll open a new PR to work on the distribution changes as agreed with Andrea and Erik https://github.com/dagger/dagger/pull/3748

[wet mason]

@rancid turret @mellow bolt @tawny flicker FYI -- I added @deprecated support in the API and codegen needs to be updated in each language to handle that: https://github.com/dagger/dagger/pull/3882

[civic yacht]

Summarized our discussion here, only new thing is that I realized it probably makes sense to now go back to using engine.Start again given these new plans, but please double check my thinking there https://github.com/dagger/dagger/issues/3830#issuecomment-1317694885

[tepid nova]

I'm guessing this is to get out of the "chicken and egg" problem of referencing digests that don't exist yet, etc?

[civic yacht]

Yeah sorta, we will still have the chicken-egg in the immediate term but the "Next step" section there describes how to break that up. Basically making the engine-session not even in the engine image anymore so it's not a weird client-server frankenstein monster anymore, just a pure client-side concept (that also is merged into the CLI too since that seems simplest)

[tepid nova]

https://tenor.com/view/cats-herding-pets-cute-kittens-gif-16995629

how this whole architecture mega-thread feels like

https://tenor.com/view/chasing-herding-goats-sprinting-goat-gif-9246988

https://tenor.com/view/cows-cattle-leave-window-gif-10696884

[civic yacht]

Hahaha it's converging though! It makes more sense than ever

[tepid nova]

Going to memorialize that one

"We have never been closer to knowing what the hell we're doing"

[civic yacht]

The asymptote is closer than ever!

[wet mason]

@civic yacht Ugh. Was trying to debug why all tests were broken after renaming a field. Turns out I also renamed it in the bootstrapped code, which used the last release (and the field was not renamed). In a weird catch 22 where the old field is now deprecated and therefore the linter won't pass if I don't switch to the new name in the bootstrap code

I'll just //nolint for now but yeah

[civic yacht]

Right so if the bootstrap code was totally independent (like in here: https://github.com/dagger/dagger/pull/3755) then it would be easier to avoid this right?

Basically, the problem is that right now all the code is intermixed so it's not possible to change "dev" code without also changing the code we use to bootstrap dev dagger?

[wet mason]

@civic yacht Yeah. Or with the separate session binary you were thinking, we could go build by hand dagger then run everything using bin://

to avoid bootstrapping shenanigans

or maybe not, it's good to use dagger for everything

[wet mason]

@civic yacht If you ever get a chance [i know you're busy with a ton of other stuff], I'd like to know if you think this PR is going in the right direction: https://github.com/dagger/dagger/pull/3827#discussion_r1023459284

https://tenor.com/view/dont-know-no-idea-dont-know-what-i-am-doing-dog-space-gif-13573944

The path handling of containers/mounts/workdir is mind boggling

[civic yacht]

Yes that's in my queue! I was just battling nodejs/typescript in the dagger-in-dagger PR and now am writing an updated description of the overall solution there (slightly modified from last week). I'll take a look at the mount stuff once I'm done writing this out

[wet mason]

Oh yeah no rush! Thank you!

[wet mason]

@tepid nova speaking of small incremental API DX improvements: https://github.com/dagger/dagger/issues/3884

[civic yacht]

Small possible dx improvement I thought of while dealing with internal/mage/util/util.go: https://github.com/dagger/dagger/issues/3885 Seems like relatively low hanging fruit?

[obsidian rover]

@rancid turret is it expected for the engine provisioning to be racy, on the Python SDK ? https://github.com/dagger/dagger/actions/runs/3487229031/jobs/5834609487#step:8:243. Am I doing something wrong on those tests ?

[rancid turret]

Maybe, so it appears. The failing test is using concurrency which passes fine on a single run. The matrix you're setting up must be running those in parallel. I'd expect that each test uses a different temp dir so need to look into that. I'm going to try simulating the parallelism in that test via my host's shell.

[obsidian rover]

Perfect, thanks. Btw, testing on python 3.10, 3.11 is ok for you or unnecessary ?

[rancid turret]

We should test all versions. It's being done in mage (sdk:python:test).

[obsidian rover]

Yes, but in the context of testing the provisioning natively, directly on host machine, on macos + ubuntu ? Does it make sense to test on several python versions ? Don't think so, just to be sure

[rancid turret]

I'm more concerned about windows vs "unix". So ideally yes, but if resource is limited we can test just one. 3.10.

[obsidian rover]

Unfortunately, as you know, impossible to have Docker on Windows (on gha runners, for now). It's on the todo queue, to check the implementation on Windows, you're right 😇

[rancid turret]

I know we can't have windows in GHA now but I don't know why.

Is it because the engine itself needs to work on compatibility yet?

Ah I see: https://github.com/actions/virtual-environments/issues/1143

[obsidian rover]

Basically, Windows hosts don't support linux containers yet (due to a mix of licensing issue: Docker Desktop Enterprise is proprietary, but would allow virtualization on Windows). In parallel, Microsoft-Hyper-V is not enabled on Windows Server 2019 images + DSv2 vm instance do not accept nested virtualization)

[obsidian rover]

yes exactly 😇

[rancid turret]

Still not making sense that error. Just tested using 4 background processes at the same time. Each test should have its own temp dir. As for the CI matrix, if you have multiple python versions, do you know if they run in different VMs?

[obsidian rover]

Yes, it's normally totally isolated. The failing test seems to be test_docker_image_provision, to run just this test

[rancid turret]

Well, looking at the log the error is happening on a single ubunbu + Python 3.10 instance.

Do you have linux?

[obsidian rover]

Not locally, but we can trigger the CI if you want

You can push on the PR btw if it helps you

[rancid turret]

I don't have access to any linux anymore.

[obsidian rover]

oh, I have a VPS

[rancid turret]

I don't have anything to push, I'd just like to run that command manually in a ubuntu host.

[obsidian rover]

Oki, I'm setting up a VPS with docker installed (have an ansible ready for that), could you please send me your public ssh key, adding you

[rancid turret]

I wonder if a recent change isn't properly cleaning that file (https://github.com/dagger/dagger/pull/3825/files#diff-76c65a2c821dfc76bfa4462edf603adda556baed638c40258c6ef65976e9edfbR109-R115).

[obsidian rover]

Does it fail on the VPS, or is it just the CI, meaning that I run the test wrongly ? 😇

[rancid turret]

Fails in VM.

But there's some changes coming to that code: https://github.com/dagger/dagger/pull/3787

[civic yacht]

@obsidian rover @rancid turret I mention that "text busy" error in the PR description of the provisioning test here: https://github.com/dagger/dagger/pull/3763

tl;dr it's essentially a flaw in Linux and there's many-years-old still-open issues for Go, Java, various build systems, etc. for it: https://github.com/golang/go/issues/22315

We have the officially suggested workaround (retry in a loop 🤷‍♂️ ) in go: https://github.com/dagger/dagger/blob/cd8c7ef9ed2f0e7d42208547cf31f4ed175dd2e3/sdk/go/internal/engineconn/dockerprovision/dockerprovision.go#L36-L52

I didn't think it was necessary in Python because our provisioning code is sync, but maybe it's still possible for sync code to run in different threads? I thought something about the GIL would stop that but I don't know enough.

It's also possible the "text busy" error could be due to something else, but this seems likely the top suspect initially

Good news if that's the case is it's extremely obscure: it can only happen on the first time provisioning a new binary happens and even then it requires that multiple threads in the same process are trying to provision it concurrently and hit a very tight time window

[obsidian rover]

Thanks, it's more clear now 🙏

[rancid turret]

Even though the provision is in sync, when called from async it executes in a thread. We can make the test sync though.

[ancient kettle]

@civic yacht When I run this snippet:

newDir := c.Directory().WithNewDirectory("/foo").WithNewFile("some-file", dagger.DirectoryWithNewFileOpts{
    Contents: "some-content",
})

Is "some-content" in the ID for newDir?

Asking because... if len(Contents) is large (say megabytes or more), that could get really nasty, really quickly.

[civic yacht]

Yes I believe it is, I think it's the same situation as before where you should only use this interface for relatively small files (you'll hit the grpc max message size limit soon otherwise). But it's definitely worsened now since the ID goes back and forth a lot.

[ancient kettle]

Cool. Just wanted to make sure I understood it correctly. Thanks!

[civic yacht]

I see, I thought that in that case only one thread could execute at a time so unless you do async calls the thread will be the only one executing. But guess not so I think we should just apply the same fix that's in the Go sdk to retry the process start in a loop a few times if we get the text busy error

[wet mason]

@tawny flicker When you get a chance this week, could you help out with @deprecated fields in node? https://github.com/dagger/dagger/pull/3882

[rancid turret]

Yeah you're right. It's in a thread but should be just one thread. I can confirm that but I'm pretty sure that's what happens with GIL.

[civic yacht]

Does the python test framework run different tests in subprocesses? The fundamental cause of the text busy error is that if the process forks while the temp file is open, even if the parent closes that file the child might still have it open (and it will be open for writing). So if the test framework runs forks concurrently with the test, that could probably also cause it

[wet mason]

@rancid turret re deprecation warnings: I implemented this Replaced by @rootfs which codegen replaces by the native symbol for the language (e.g. Replaced by Rootfs in Go). Thoughts? /cc @tawny flicker

[tawny flicker]

This community call was packed with demos!!

[tawny flicker]

I'll add that for my tomorrow

[rancid turret]

Yeah, sounds good to me. I can even make it a link to the new field 🙂

[wet mason]

Nice 🙂

[strong coral]

Do you have an example of what the query looks like for a go build?

[civic yacht]

Yeah you re right It s in a thread but

[wet mason]

Trying to regroup small API wins we can do quick:

• Deprecate fs in favor of rootfs: https://github.com/dagger/dagger/pull/3882
• Deprecate workdir in favor of directory(".") https://github.com/dagger/dagger/issues/3828
• Support WithDirectory/WithFile directly on a Container (Dockerfile pattern) https://github.com/dagger/dagger/issues/3827
• Simplify WithNewFile https://github.com/dagger/dagger/issues/3884
• Rename exec to something less confusing https://github.com/dagger/dagger/issues/3709

Anything else @tepid nova @hasty basin @civic yacht @cosmic cove ?

[tepid nova]

checking the size/small label just in case...

https://github.com/dagger/dagger/issues?q=is%3Aopen+is%3Aissue+label%3Asize%2Fsmall

There's WithHostname: https://github.com/dagger/dagger/issues/3582

[civic yacht]

I think the Stat issue from that size/small list is pretty easy (it's already in the gateway api, we just need an interface to it) and also pretty nice-to-have (running stat as an exec is an unfortunate workaround): https://github.com/dagger/dagger/issues/3764

[tepid nova]

There's also the "pulling golang" in the logs, https://github.com/dagger/dagger/issues/3733

(not sure if that's an easy win though)

[civic yacht]

No that's medium to hard depending on the approach

[cosmic cove]

would this count? https://github.com/dagger/dagger/issues/3887

[tawny flicker]

Actually, I will be at the DevFest Strasbourg tomorrow. I'll try to have a look right now.

btw @cosmic cove , what does the green and red color mean in the dates of this document : https://docs.google.com/spreadsheets/d/14tSa735AQp5inrPfreaX6AW3CGWx0J6NThLBbloPWrg/edit#gid=0 ?

[cosmic cove]

I think that means that those are complete

[wet mason]

Can I get some eyes on the first one? It's the first deprecation we do (includes the deprecation mechanism), all others are blocked on this

[civic yacht]

I just thought of what I think is a relatively easy way of being able to mount the shim binary into exec ops direct from the engine image host fs (oci runtime hooks), updated this issue's description with the idea: https://github.com/dagger/dagger/issues/3733

Should solve that problem of building the shim on the fly (and also help out with the remaining ugliness mentioned in the dagger-in-dagger pr: https://github.com/dagger/dagger/pull/3787)

@wet mason @tepid nova I think this is a pretty robust approach actually (all my other previous ideas were either huge hacks or huge efforts), but let me know if you disagree or have any experience with oci runtime hooks. Before this I knew they existed but haven't used them yet.

[wet mason]

I assume that would require customizing the bk image?

Just commented with the nastiest hack as a possible stupid simple alternative (not advocating for that, tons of cons, just had to put it there)

[civic yacht]

I assume that would require customizing the bk image?

We already have a custom image (the engine image), so yes but that's no longer much to ask.

[wet mason]

Right -- I forgot for a second we're actively rebuilding it, not just "rebranding" it

So there's our hook

[tepid nova]

Speaking of third-party images, I remember seeing that we pull a binfmt image from tonis's personal docker hub account or something, for multi-platform? Is that right and if so, is there an issue to track changing that?

[civic yacht]

https://github.com/dagger/dagger/issues/3801#issuecomment-1318976843

[tepid nova]

Ah currently users have to run it manually?

So our "source of truth" is a guide somewhere in our docs I'm guessing

[civic yacht]

If they want emulation to work yes. It's the same state as docker build{x} users for now. It's mentioned in the requirements here: https://docs.dagger.io/sdk/go/406009/multiplatform-support

But as @hasty basin pointed out in the zoom meeting earlier that's not good because it's a requirement that applies to all of our SDKs, not just Go

So we need a language agnostic section or something. @cosmic cove do you know if there's any existing issue for this? I forget what was mentioned in the Zoom chat

[cosmic cove]

No, we don't have an issue for it, but I will create one right now. The experience was discussed a little bit when we were figuring out how to structure the docs, but we tabled it to get something out asap. I'll move it up on Vikram's radar.

[tepid nova]

What would be useful is an issue tracking all the documentation content that may be needed outside a SDK section. (including this one). That would help avoid one-off decisions we regret later

[cosmic cove]

https://github.com/dagger/dagger/issues/3909

[tepid nova]

Thanks! I replied there

[wet mason]

Thanks @civic yacht!

Any comments on rootfs naming? @tepid nova?(https://github.com/dagger/dagger/pull/3882)

[tepid nova]

Didn't we discuss that in an issue already?

[wet mason]

Yep, just triple checking before making an API change

avoid surprises

[tepid nova]

Ah, https://github.com/dagger/dagger/issues/3673

Right

[wet mason]

thanks

[rancid turret]

Deprecation patterns

[obsidian rover]

@civic yacht or @wet mason , I can't seem to understand why ExampleContainer_Build only times out on the CI (go sdk): https://github.com/dagger/dagger/actions/runs/3492774906/jobs/5846902028#step:6:311. Any hint would be helpful (whenever you have some free time)🙏😇

[obsidian rover]

Is it because, with virtualization, it takes time and times out ?