maintainers

[wet mason]

Try to put a much longer time out, see what happens?

@wild zephyr Hey, I don't know it's not triggered by CI, but I just ran golangci-lint locally and got a few CLI warnings:

WARN [linters context] rowserrcheck is disabled because of generics. You can track the evolution of the generics support by following the https://github.com/golangci/golangci-lint/issues/2649. 
cmd/dagger/exec.go:45:3: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
                http.Serve(l, nil)

no idea why CI isn't picking this up

[wild zephyr]

@wet mason maybe warnings are not making the linter to exit with an error?

I can check tomorrow 🙏

[wild zephyr]

Oh! It's not a warning actually. I'll fix that

[hasty basin]

Is it actually possible for our Go SDK examples to run in go.dev?
https://pkg.go.dev/dagger.io/dagger#example-GitRepository

[tepid nova]

I hope not, for their sake

[hasty basin]

They always show that if you try to run them

Def seems like suboptimal, but if Go devs all know that it's not the "real" Go way to try things, then we're good, I suppose. I don't have the cultural frame of reference.

[tepid nova]

That seems more like a go.dev problem, we're probably not the only Go library with examples that don't magically run in their sandbox, because of external side effects

[tawny flicker]

Yes, any network connection attempt is stopped to avoid ddos attack from some go.dev runner going wild.
And even imports of external modules/packages is not allowed.

[tepid nova]

@wet mason @civic yacht re: small wins. I remember we discussed simplifications of 1) how to pass argument to exec, and 2) stdout/stderr (skip the contents field). Do you remember what issue that was in by any chance?

[hasty basin]

As long as you don't try to run them, the go.dev docs come pre-loaded with the expected output, which is nice 🙂 guessing the team supplied those.

[tawny flicker]

Yes, it is a way to actually test your code examples directly

[tawny flicker]

https://go.dev/blog/examples

[civic yacht]

I think I mentioned 2 as part of this big ol thread: https://github.com/dagger/dagger/issues/3555#issuecomment-1301530430. 1 isn't ringing any bells for me right away though

[wet mason]

I remember but I don't remember the issue

making it "weird" for the 1% (e.g. Exec with no args needing to pass empty args) looks appealing to me

[tepid nova]

Yeah definitely

Not even that weird

[wet mason]

yeah yeah

[wet mason]

For 2 -- I'm a big proponent of skipping the contents field, but there's that 1% use case that's not really doable without: mounting a stdout as a file to another exec (e.g. "kinda unix pipes"):

e.g. ctr.WithMountedFile("/out", ctr2.Exec("ls").Stdout()).Exec("cat", "/out")

But eh, I think the 99% of Stdout() do not need this whatsoever

[civic yacht]

If we still want that functionality it could just be a separate api (i.e. StdoutFile()) so the 1% just have to deal with a clunky name

[wet mason]

uhhh that's neat

@tepid nova if you think of any other small win, send them my way

[tepid nova]

I would actually use redirect to a file for this

which should be an exec opt anyway

[wet mason]

which IS an exec opt

actually

[tepid nova]

wat

[wet mason]

so nevermind my comment

@tepid nova you added it to the spec, at some point it just got implemented

[tepid nova]

https://tenor.com/view/speed-gif-5593963

[wet mason]

I think when Alex was going through the whole spec he just added whatever didn't exist yet

[tepid nova]

new feature: both clients AND server implementation are generated from the graphql schema

[wet mason]

https://tenor.com/view/why-not-both-por-que-no-los-dos-yey-gif-15089379

love the new @deprecated graphql annotation, codegen, and docs linting working together

My @deprecated host().workdir PR is failing CI because:

docs/current/sdk/go/snippets/get-started/step4/main.go:29:9: SA1019: client.Host().Workdir is deprecated: Use Directory with path set to "." instead (staticcheck)
        src := client.Host().Workdir()

[civic yacht]

https://tenor.com/view/kronk-its-all-coming-together-gif-15058130

[tepid nova]

is it emitted by the generated client? Or the engine / session helper?

[wet mason]

@deprecated is standard graphql -- codegen is transforming that in native deprecation warnings in each language

and then the go linter does the usual linting, complains about using deprecated functions

so the generated client is not doing anything special, this is regular Go tooling we integrate with by following standard deprecation warnings

In Python, @rancid turret formatted the comment so you even get a link to the replacement function automatically, which is pretty amazing 🙂

https://dagger-io--3910.org.readthedocs.build/en/3910/api.html#dagger.api.gen.Host.workdir

[tepid nova]

@cosmic cove @hybrid widget : we should add this to the queue as an engineer blog topic 🙂 ☝️

[wet mason]

So basically, my PR just added the @deprecated symbol:

  workdir(exclude: [String!], include: [String!]): Directory!
     @deprecated(reason: "Use `directory` with path set to '.' instead.")

codegen converted that in the 3 SDKs to native deprecations

• go lint is failing my PR automatically because we're using deprecated stuff in the docs
• pkg.go.dev will display a deprecation notice
• readthedocs in python will display the notice, link to the directory() replacement
• our own reference docs for nodejs display a deprecation warning (https://deploy-preview-3910--devel-docs-dagger-io.netlify.app/current/sdk/nodejs/reference/classes/api_client_gen.Host#workdir)

it's pretty cool now to change our mind and rename fields

[tepid nova]

be careful what you wish for

[wet mason]

@civic yacht (:radar: since you're working around those parts) just noticed a problem ... WithDevEngine doesn't bust the cache

For instance, with python:generate, if the API changes but nothing in sdk/python, then the generation doesn't happen

not seeing that in go and ts since we generate using the cloak binary, so if that changes, the other stuff changes to

I have a workaround so not a blocker or anything

[civic yacht]

Where does WithDevEngine come into play? That just builds the engine from local code, runs it in docker, and then wraps whatever you want in that engine. If python:generate isn't running I wouldn't have thought that would have anything to do with the dev engine part

[wet mason]

Not WithDevEngine specifically, just the overall pattern. Making changes to the engine doesn't alter pipelines that "use" the engine as input to produce their output

[civic yacht]

I see, yeah that's interesting. I have an issue open somewhere about possibly including versioning information in the cache so it can be invalidated if we change an API changes implementation in a meaningful way, but that's a pretty big project.

For this specifically I guess the schema is a "remote resource" and we want to only run something when that changes. Similar to (in an abstract way) exec ops that run deployment (deploy my site not only if my code changed, but also if the remote resource changed). So in that sense "no-cache" would be one solution.

But not ideal of course

[civic yacht]

Got the oci runtime hook of the shim working: https://github.com/dagger/dagger/pull/3913 Really excited by all the possibilities it unlocks actually, besides just fixing the immediate problem of the shim being built on the fly (now it's just bind mounted in from the engine image). Among other things, I think it might let us take dagger-in-dagger out of experimental mode in combination with my other PR for the fully isolated nested sessions

[wet mason]

Damn that's impressive 🙂

Just reviewed, LGTM, just a general question

@civic yacht that's so cool. Super excited about everything we can do now

That plus the networking changes Alex mentioned in bass (container-to-service networking) and we'll have a really awesome "runner" setup

[tepid nova]

I don’t understand it, but I’m excited too 😁

[wet mason]

https://tenor.com/view/captain-phillips-boat-hijack-im-the-captain-now-barkhad-look-at-me-gif-4242563

That's the summary of the change

[tepid nova]

lol dagger taking the driver’s seat

https://tenor.com/view/grand-theft-auto-steal-car-gif-15390870

[wet mason]

Rather than tweaking our llb.Run calls to prefix everything with our shim we injected separately, we're the OCI runner now and part of the buildkit image

well, the engine image

So we wrap runc, and runc makes sure the shim is shimming

[civic yacht]

Coincidentally containerd has its own thing called shims which are pretty much exactly what we have now (just without needing to also setup a full containerd daemon yet)

But yeah, basically we can completely customize each container now. With great power comes great responsibility and all that, but it's extremely nice to have as an option going forward

[tepid nova]

Very secondary benefit but… this will make IDs slightly less monstrous right?

[civic yacht]

Yes they won't have a full Dockerfile embedded in them anymore

Shims don't exist as far as they know

[tepid nova]

Awesome

I actually discovered the embedded Dockerfile earlier today while debugging a pipeline. base64decode -> jq -> waaa?

Thought it was picking up a dockerfile on my repo somewhere somehow 😅

[obsidian rover]

https://tenor.com/view/yoda-amazed-i-am-amazing-amazed-star-wars-gif-26053868

[hybrid widget]

Captured in https://github.com/dagger/dagger/issues/3916

[remote jetty]

👋 Is there any instructions for contributing e.g. running the dagger engine locally? I'd like to tinker around with it for a pull request, but I can only find what looks like an out of date contributing doc

[obsidian rover]

Hi,
The engine already runs locally when you run your pipeline. Do you have a more precise contribution idea you would love to work on? 😇

run engine locally

[civic yacht]

@wet mason when you have a min can you take another look at the fully nested sessions pr: https://github.com/dagger/dagger/pull/3787

Should be good to go now. I'm working right now on a follow up that combines it with the oci runtime wrapper update, which I think will let us take dagger-in-dagger out of experimental mode and simplify even more. Should be doable today barring unforeseen roadblocks. But would prefer that's a separate PR as the nested session one has stuff relevent to @wild zephyr work (DAGGER_RUNNER_HOST) so don't want to over entangle it

[wet mason]

sure!

[rancid turret]

@wet mason, can we merge https://github.com/dagger/dagger/pull/3910 ? I need to make changes to docs examples.

[wet mason]

@civic yacht note for our future selves: That mount of .docker got me thinking: dedicated sessions are a double edged sword

• When we'll do something fancier for logs rather than just dumping to stderr (e.g. stream over API and have a nice display), we'll only see the "outer" session logs (currently it works just because all sessions are dumping to stderr in cascade)

• If we had a cloud integration that provides visibility into the graph (timing, cache status, ...) we'd only see the outer layer

• OpenTracing would also stop at the outer layer

I don't know what the future holds. Either going back to "virtual sessions" with proper support in the session manager for nesting/sandboxing, or have some continuity between session managers

[wet mason]

done

[civic yacht]

It's hard to say since our future plans for logging are vague but I would imagine that no matter what there's a good chance we'll need some way of "aggregating log streams", which makes me think that we can just use that to combine log streams from different sessions. And for tracing we'll definitely need a way to pass "context", so if we make the tracing and log stream target both passed through that context and context passed between nested sessions, that seems like it should do it (without requiring we rearchitect other stuff around it).

But yeah, there's about 10 layers of hypotheticals there so not sure yet either. Think we at least have plenty of options

[wet mason]

@civic yacht Yup. And the process is the same, we'd have to pass some "sub-session" ID to the nested (or extended) dagger, whether it's via a binary or header doesn't make much difference

For logs, even though they're far away, I was thinking we could experiment pretty fast. Even without "streaming", currently it's trivial to switch logging to json and parse outside to do some nice visualizations

[tidal spire]

I vaguely remember this mentioned somewhere at some point, but want to verify:
is .git/ automatically excluded from Host().Directory()?

[civic yacht]

No it shouldn't be automatically excluded from host dirs. It is automatically discluded when you use .Git(...) and related apis (but can be toggled on now thanks to a recent contribution)

[tidal spire]

That's what I was thinking of, thanks!

[cosmic cove]

yes, totally! https://github.com/dagger/dagger/issues/3920

[wet mason]

Can I get a quick review (should take a few seconds) on this one? https://github.com/dagger/dagger/pull/3912

It's annoying to make API changes without this

[strong coral]

Should a query be encased in query{} ? The graphiql web app seems to want it, but dagger query does not.

[wet mason]

@strong coral No need, it's the default. Not sure why graphiql would want it

it's query{} vs mutation{}, defaults to query

[strong coral]

Ah, it's not the query keyword it wants, just the extra curlys

[wet mason]

Oh yeah, that's needed

[strong coral]

But dagger query throws Error: input: Unknown operation named "query{container{from(address:mcr.microsoft.com/powershell){exec(args:[echo,hello]){stdout{contents,size}}}}}"

[wet mason]

address, each element of args needs to be encased in double quotes. Not sure why the error is different than graphiql? I suspect because graphiql parses the query client side whereas dagger query just sends it verbatim to the server /cc @wild zephyr

[strong coral]

No, it's a stdin synax difference. This works for me.

$query.Build() | c:\source\github\dagger\bin\dagger.exe query
{
    "container": {
        "from": {
            "exec": {
                "stdout": {
                    "contents": "hello\n",
                    "size": 6
                }
            }
        }
    }
}

[wild zephyr]

@strong coral how are you calling dagger query?

[strong coral]

I was trying to pass the query as a string argument

Pipe to stdin works

[wild zephyr]

that makes sense, if you check the query help, the only argument that it accepts is a graphql query operation name.

This way, if you have multiple queries in a single file you can select which to run. i.e:

./dagger query <<EOF foo
query foo {
  container {
    from(address:"hello-world") {
      exec(args:["/hello"]) {
        stdout {
          contents
        }
      }
    }
  }
}

query bar {
  container {
    from(address:"hello-world") {
      exec(args:["/hello"]) {
        stdout {
          contents
        }
      }
    }
  }
}
EOF

if you don't specify an operation name, this fails since it doesn't know which one to run

[strong coral]

PS > $results = $query.Build() | dagger.exe query | ConvertFrom-Json
PS > $results.container.from.exec.stdout

contents size
-------- ----
hello…      6

Are there any functional or performance differences between using dagger query and dagger-engine-session?

[tepid nova]

• dagger is a user-facing client tool which uses dagger-engine-session under the hood like all other clients.
• dagger-engine-session is a low-level tool which should not be used directly

There should be no performance difference (same code path under the hood)

[wet mason]

May I have another quick review (1 liner -- plus fixing all tests/docs): https://github.com/dagger/dagger/pull/3911/files#diff-c98167afc909eb85b3953bb2e53a1181a612423cebaccbcf5135e241fa1f400dR24

I'm trying to batch all quick API wins today, so I'll have a few of those ones coming up

[tepid nova]

I'm doing the opposite 😉 Writing down those longer-term topics we keep talking about but never get around to create issues for: https://github.com/dagger/dagger/issues/3923

@wet mason should we schedule a combined release to flush all those pending changes to users?

[wet mason]

Yeah. I'm trying to get them all in today

Python has a pending big change (hiding IDs) that needs releasing soon, I figured might as well jump on that train

[wild zephyr]

TIL to get VCS information in the go binary you actually need the git CLI to be present in the PATH from where you're building . Just having the .git folder is not enough cc @tawny flicker since we had some experiences with this in the past

[tidal spire]

I can't wait for an amazing secrets integration, but in the mean time it's super cool that I can do this: https://github.com/kpenfound/hello-nomad/blob/main/ci/utility/secrets.go#L26-L48

[wet mason]

CI is broken on main because of two conflicting PRs. Fix here: https://github.com/dagger/dagger/pull/3922

[wet mason]

Review queue:

• WithNewFile: mandatory contents https://github.com/dagger/dagger/pull/3911
• Stdout/Stderr: No need to call Contents(): https://github.com/dagger/dagger/pull/3925

Working on WithExec + mandatory args. So far, all changes combined together are much nicer:

        // List files
-       out, err := container.Exec(dagger.ContainerExecOpts{
-               Args: []string{"ls", "-lR", "/embed/"},
-       }).Stdout().Contents(ctx)
+       out, err := container.WithExec([]string{"ls", "-lR", "/embed/"}).Stdout(ctx)

[ancient kettle]

I like it, @wet mason. Definitely feels cleaner.

[dapper tinsel]

@wet mason I wonder if we should retain a way to retrieve a stdout *dagger.File. It's useful for something like secret := withExec.StdoutFile().Secret()

[wet mason]

@dapper tinsel Already doable! The syntax is a bit longer but it's rarer case than just grabbing stdout

ctr.WithExec([]string{...}, dagger.ContainerWithExecOpts{
  RedirectStdout: "/mysecret",
}).File("/mysecret").Secret()

[dapper tinsel]

I see. I misunderstood and thought you completely removed dagger.ContainerWithExecOpts with a args slice. 😄

@wet mason Another suggestion: should the contents parameter be of type []byte instead of string? It's weird having to cast a binary to string.

[wet mason]

Oh, it's still there -- required arguments are positional (ctr.Exec(mandatory1)) while optional arguments are in the struct (ctr.Exec(mandatory1, dagger.ContainerExecOpts{Optional1: xxx}))

so I made args required to move it to positional

[wet mason]

Unfortunately that's an API limitation since we're built on top of GraphQL, there's no []byte

[wet mason]

Review queue:

• WithNewFile: mandatory contents https://github.com/dagger/dagger/pull/3911
• Stdout/Stderr: No need to call Contents(): https://github.com/dagger/dagger/pull/3925
• Deprecate Exec in favor of WithExec with mandatory args https://github.com/dagger/dagger/pull/3928

[dapper tinsel]

Probably we can follow golang encoding/json that marshals []byte to base64 json string?

[oak sandal]

It looks like I can't really import dagger.io/dagger (main branch, not the latest tag) on a mac. It complains about build constraints. Am I missing something obvious?

[oak sandal]

Hey folks, would appreciate thoughts/review on this PR: https://github.com/dagger/dagger/pull/3938

[remote jetty]

@tepid nova @civic yacht I've made a draft pull request to support private registries.

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

I suspect things have changed since last week so if someone else has already looked into this that's fine, we can 🚮 🙂

[tepid nova]

Should we remove the #github-feed channel? Does anyone rely on it?

(I'm looking for opportunities to reduce discord noise incrementally)

[rancid turret]

I use it 🙂

Helps me reduce github notifications noise.

[rancid turret]

@civic yacht How can I test outside of dagger-in-dagger with dev version of engine? I've run engine:dev, docker cp the binary from test-dagger-engine and run tests with DAGGER_HOST=bin://.

Error: failed to run container: Unable to find image 'ghcr.io/dagger/engine:10f4c5bea6c524575157116d3acc6ffd6fc3a526'

[civic yacht]

I think this broke over the weekend with the CLI commit, it's defaulting to use an image that doesn't exist yet, for now try setting DAGGER_RUNNER_HOST=docker-container://test-dagger-engine

[rancid turret]

That works, thanks!

[civic yacht]

I'll go look at that and see what other short term fixes there are before the cli stuff is done

[rancid turret]

I'll add a docker-container connector to make this easier.

[tepid nova]

I worry that we’re losing control of the env variable matrix

[civic yacht]

https://github.com/dagger/dagger/pull/3929 Documentation PR here, also was just talking to Andrea about it a bit more. Will keep docs updated as it moves

[tepid nova]

For now can we agree on a freeze to more environment variables until we agree on an overall plan?

[civic yacht]

Yeah there's no plans on adding any more right now

[tepid nova]

I would like to kill DAGGER_HOST as soon as possible, and add a prefix for those that we know/suspect will be deprecated

like maybe a leading _ or something like that

[rancid turret]

What do you have in mind to replace DAGGER_HOST? I have no context on that.

[tepid nova]

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

the problem with DAGGER_HOST is that many users are looking for a way to run remote engines and are confused by how. This var name adds to the confusion

[rancid turret]

I see

[tepid nova]

that + the format of the variable value itself (complex)

meanwhile There is pressure to offer an alternative to BUILDKIT_HOST (or bring it back)

[civic yacht]

I'll write a comment on that issue what Andrea and I were just talking about. It has overlap with the user requests coming in and the CLI stuff too anyways.

[tepid nova]

@civic yacht feel free to open a new issue if the proposal is broader

Whatever helps clarify context

[wet mason]

@wild zephyr Any reason this is needed at all?

    if err := parseRef(refName); err != nil {
        return err
    }

vs doing nothing?

[civic yacht]

I think it makes sense there right now, I did the quickest possible brain dump of the latest thinking. Will not make any changes in that direction until we have agreement on the overall approach though. https://github.com/dagger/dagger/issues/3830#issuecomment-1322598190 cc @wet mason

[wet mason]

@tepid nova ^^^

That's what we brainstormed so far. Attempting to combine #3830 ("DSI"), with the couple OX user requests we got so far, with the "current architecture reality" (there's 2 API endpoints right now -- bk and gql), while trying to simplify SDKs (they shouldn't deal with docker whatsoever anymore)

[rancid turret]

Are these changes for next release?

Sounds like after, right?

[civic yacht]

No, there's probably not time, so this will be after the upcoming graphql/cli release

[rancid turret]

Ok. For now what do I do with the new image ids? The digest based one doesn’t work on main so I suppose I should update now to assume git sha tags right? Support for main tag?

[civic yacht]

I think the only change needed in the short term is that the SDKs should just also set DAGGER_RUNNER_HOST. So like when you use the default DAGGER_HOST=docker-image://<ref+sha> they also need to set DAGGER_RUNNER_HOST to the same value. That's what the behavior was before essentially and I think the changes merged this weekend just missed that

[wet mason]

as soon as we publish the engine, it'll open a PR to bump the git shas (sdk:all:bump)

[rancid turret]

Yeah but right now python is digest based not sha based, that's what I'm asking.

Need to mirror go, right?

[civic yacht]

The SDKs will continue using default image refs that look like this: https://github.com/dagger/dagger/blob/67b02cdafce581a8c863e75769adc28f9c7db2c4/sdk/python/src/dagger/connectors/engine_version.py#L4

They won't switch to using the git commit sha yet

[rancid turret]

That's not what I'm seeing, hang on... let me take a closer look.

[wet mason]

[chatting about this at the same time]

[rancid turret]

EngineImageRef = "ghcr.io/dagger/engine"
...
engineImageRef := fmt.Sprintf("%s:%s", EngineImageRef, commitSHA)
...
sdks.Bump(ctx, engineImageRef);

What am I missing?

[wet mason]

@rancid turret missing nothing

figuring this out, one sec

[tepid nova]

I replied @wet mason @civic yacht . I think we can cut some of the feature set and complexity.

I wonder if some of the features in the proposal are there because it makes our job easier (for testing SDKs). That's completely understandable, but if that's the case we need to find a way to help ourselves without moving more complexity to users and 3d-party developers.

[civic yacht]

Okay yeah we need to do some reconciliation with that change over the weekend. Talked w/ @wet mason about this:

1. Have engine:publish go back to publishing using the git tag (w/ fallback to main), same as before
2. The CLI will switch to burning in just the git tag (same as before), with a fallback to main for dev builds and use that to pull the engine image
   • This is based on the assumption that for now any use of non-released images/cli builds will just use our local dev tooling (./hack/make ...)
3. SDKs will need to automatically set DAGGER_RUNNER_HOST when not set already to replace the previous use of --remote that got removed
   cc @wild zephyr

[rancid turret]

Ok thanks 👍

[wet mason]

Yeah, we were just discussing this -- agreed we can cut a bunch of that stuff

[tepid nova]

I just spent 15mn on that follow-up comment @wet mason @civic yacht and it's unclear to me what we agree on and what we don't. Because "URL" could mean many different things. That in itself is reason enough to not use it.

[wild zephyr]

marcosnils3545 Any reason this is needed

[still garnet]

vacation catch-upreading list

[civic yacht]

PRs we should merge before doing an engine/sdk release:

• https://github.com/dagger/dagger/pull/3826
• https://github.com/dagger/dagger/pull/3949
  cc @wet mason

[wild zephyr]

@wet mason @civic yacht engine pushes back to 🟢 (https://github.com/dagger/dagger/actions/workflows/publish-engine.yml). I'm aware that there are still chaning some things, but at least we're ready for a new SDK release when you see it appropriate. I'll focus on the CLI distro now

[wet mason]

reviewed

I'm going to be offline for the next 30-ish minutes (need to move somewhere else)

[wet mason]

(almost done prepping the pipeline PR)

(testing a few times)

[civic yacht]

@strong coral Hey Chris, if you have a free moment sometime I have a Windows question (starting thread)

[wet mason]

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

@civic yacht @wild zephyr re: CLI release

If we do nothing, we're good to go with the CLI release

1. Publish engine
2. PR gets opened to bump Go SDK's engine dependency. Merge
3. Build CLI from source. CLI uses correct version of the Engine

So long as we merge step 2, the CLI using the Go SDK will use the right version (e.g. we don't need to switch to engine.Start next week)

We have to at some point, but it's not a hard requirement for next week

Was pretty tired yesterday and didn't realize this

[wild zephyr]

yep, that's why I was confidently working on the CLI release pipeline today. Since we don't have to do anything. I'm just moving the goreleaser dagger pipelines to the engine mage publish targets

so once the engine:publish is called, the CLI release pipelines also trigger

[wet mason]

@wild zephyr Great! Yeah it might have been obvious but was tired and couldn't brain yesterday afternoon

[wild zephyr]

haha, np! quick question: we can force push ghcr tags, right? Since it could happen that the ghcr push works but goreleaser fails for some reason. In that case we'd have to re-run the release pipeline

[wet mason]

Makes a lot of sense

Eventually:

• CLI will use engine.Start etc (basically it will do whatever the session binary is doing)
• CLI is built using -X main.Version=<tag> (already the case)
• CLI uses that version to pull the engine (which gets published with the tag as well)
• SDKs download CLI using that same version, from the S3 bucket (e.g. where goreleaser is already putting the binaries)

So it's going to be much simpler. Push the engine to the registry, push CLI to s3, done

SDK grabs CLI vX, CLI grabs engine vX

[wet mason]

should be the same. At least we can delete tags

[wild zephyr]

👍 great

@wet mason does it make sense to add some README instructions on how to use the latest main engine with the dagger CLI now? Since if users clone the repo, build the engine and do a dagger listen they'll be using the latest released engine image which is a bit confusing. They currently need to do engine:dev and export the variables to get the "dev" one.

I know this will change with the upcoming changes. Just wondering if it's worth to document somewhere in the meantime

[wet mason]

Yeah I think so. That document should always exist, upcoming changes will just make it shorter

[wild zephyr]

👍 will send a PR with a brief README in cmd/dagger shortly

[wet mason]

@civic yacht @wild zephyr main CI is almost green -- should I go ahead and tag an engine release? Anything else blocking?

[civic yacht]

Nope should be good to go I think

[wild zephyr]

all good here

[wet mason]

https://github.com/dagger/dagger/actions/runs/3527045323/jobs/5915664170

in progress

[wet mason]

@civic yacht 🍾 https://github.com/dagger/dagger/pull/3962

[civic yacht]

The docs don't release immediately? I was waiting for the Go SDK release but I guess the timing isn't important to get exactly in sync

[wet mason]

Oh, nope, manual on purpose

they would be super broken right now otherwise (WithExec, etc)

[civic yacht]

Oh duh

[wet mason]

https://devel.docs.dagger.io <-- auto release

https://docs.dagger.io <-- manual

[civic yacht]

Makes sense, shipit!

[wet mason]

ah crap. linter broken because of bump

@civic yacht running all tests manually locally for provisioning ...

[civic yacht]

Was doing that too already 🙂 but we can have double the verification

[wet mason]

Haha 🙂

which ones did you do?

[civic yacht]

nodejs so far

[wet mason]

cool

i did everything EXCEPT node

python is finishing up

https://tenor.com/view/spiderman-funny-point-no-you-gif-13270861

python passed

Go did work but I don't have anything in ~/.cache/dagger

I'm re-running go test from sdk/go

Pass

But still nothing in the cache

[civic yacht]

on macos?

[wet mason]

yeah

oh btw -- go clean -testcache. go test was itself cached

so tests are passing, the right engine is provisioned

but ~/.cache/dagger is still empty

[civic yacht]

Hm yeah I get the same behavior... the provisioning test in the go sdk override XDG_CACHE_HOME so it's expected for that, but it should get cached from the other tests

[wet mason]

ah!

~/Library/Caches/dagger

I think?

[civic yacht]

Haha I was just about to paste that!

sipsma           73092   0.0  0.1 409239120  79008 s001  S+    3:41PM   0:00.73 /Users/sipsma/Library/Caches/dagger/dagger-engine-session-41f71f0036167fcc

[wet mason]

So just a different behavior between languages -- in Go it's the "correct one"

[civic yacht]

Ok yeah we use an actual xdg library in Go whereas the other SDKs just check XDG_CACHE_HOME and default to ~/.cache/. So I'm guessing that ~/.cache is the default value of XDG_CACHE_HOME on linux but that library must set it to something else on macos

[wet mason]

Maybe we should do the non-Go thing in Go as well

[civic yacht]

Yeah, not actually harmful, but I'll open an issue as it's worth making consistent

[wet mason]

Cool so everything works

ready to 🚢

[wet mason]

Go: https://github.com/dagger/dagger/actions/runs/3528065534/jobs/5917767099

[hasty basin]

earlier today my pipelines on my mac were using ghcr.io/dagger/engine:v0.3.4 I think and now they're using moby/buildkit:v0.10.5. Expected?

[civic yacht]

No everything should be moved off using moby/buildkit now, but that would pop up if you ran some old code that still used the previous image. Do you know what you ran that caused moby/buildkit to appear?

[hasty basin]

the getting started code

[civic yacht]

for which SDK?

[hasty basin]

golang

will try to repro again. noticed it while trying to troubleshoot someone

[civic yacht]

I think if you ran it including go get dagger.io/dagger@latest then you'd end up with the latest released go sdk, which is the older code that still used moby/buildkit

[hasty basin]

like this? https://docs.dagger.io/sdk/go/371491/install
https://docs.dagger.io/sdk/go/959738/get-started#step-3-add-the-dagger-go-sdk-to-the-module

[civic yacht]

Yeah that, though now that the new go sdk is being released @latest should start resolving to the new moby/buildkit-free implementation soon

[hasty basin]

https://tenor.com/view/crypto-drop-ripple-ripples-tradecryptolive-gif-16110011

so no PR needed, just let it propagate?

[civic yacht]

Yeah the final step is to just create the tag for the release in github, after which we just need the signal to make its way around the world

[wet mason]

Python SDK is publishing

Done: https://pypi.org/project/dagger-io/#history

Node SDK is publishing

Done: https://www.npmjs.com/package/@dagger.io/dagger?activeTab=versions

Docs are live

[wet mason]

@tepid nova @ancient kettle @stray heron We should consider retiring / renaming the dagger GHA, I've seen a few occurrences where someone tried to use it with non-CUE

[wild zephyr]

FWIW playground also upgraded accordingly

[hasty basin]

Dagger GitHub action

[tidal spire]

anyone working on updating go pipelines from 0.4.0 -> 0.4.1, here's a cheat sheet: https://github.com/kpenfound/greetings-api/commit/cf531d66c9a766fbac775540b15a92ba9a4e2a3b

will have the same for python and nodejs shortly. Are we publishing any sort of official announcement for the new versions?

[hasty basin]

@tidal spire these changelogs mention changes: https://github.com/dagger/dagger/releases/

[stuck bloom]

There's this also 🙂 https://github.com/dagger/dagger/issues/3883

[tepid nova]

@wet mason @civic yacht follow-up on DSI, followed by a change of heart 😉

[civic yacht]

Got back there!

[tepid nova]

https://tenor.com/view/pingpong-pingpong-ani-anime-rally-sports-gif-17683396

[civic yacht]

That's right, we're not just nerds commenting on github issues!

[tepid nova]

Yes. We are cool!

You get it

They say you can make a thrilling, award-winning manga series about anything. I'm confident our time will come.

[civic yacht]

cc @round vapor need a Dagger manga someday 🙂

[tepid nova]

https://tenor.com/view/squad-crew-anime-fairy-tail-gif-17203545

[tepid nova]

@civic yacht one fun hack, with the DAGGER_SESSION_PORT approach, you can replace dagger listen advantageously with dagger run sh -c 'echo "http://localhost:$DAGGER_SESSION_PORT/$DAGGER_SESSION_PATH" ; read'

[civic yacht]

Erik Sipsma3294 one fun hack with the

[wild zephyr]

@still garnet around? I thought Host.Directory didn't allow referencing any arbitrary dirs in the host and was only scoped to the cwd? Just checked with @hybrid widget and seems like it's not the case.

[still garnet]

it's not restrictive, you can pass absolute paths - you just can't do ../

for non-security-related reasons

context: https://github.com/dagger/dagger/pull/3401#discussion_r997304282

[wild zephyr]

still a bit confused. With the current model you can't basically rely on any third party pipeline imports since there's no way to know if those pipelines will try to read arbitrary files from the host machine (?)

[still garnet]

correct, to my knowledge those safeguards haven't been implemented yet; it hasn't been a priority as we haven't focused on extensions yet

[wild zephyr]

gotcha, good to know. Thx for sharing ❤️

[tepid nova]

@wild zephyr same security profile as any other go library you might import

extensions will improve the security model

[wild zephyr]

Makes sense, I didn't think about it that way. Also GitHub actions have the same properties as well

[tepid nova]

We can definitely do better - with extensions 🙂 But at least for now we’re not making things worse

[slate hawk]

Update multibuild concurrency by kpenfou...

[flat heart]

Hi there, how can I push to an insecure registry whith go sdk ?

[wild zephyr]

👋 can you please post this in #1030538312508776540 ? Thanks!

[flat heart]

ok thanks !

[tepid nova]

Starting a thread of OX (operator experience) requests and issues, I’m seeing more and more pop up

[civic yacht]

@rancid turret Quick question, did switching to httpx enable the python sdk to connect to the engine over unix sockets? Or is it that going to require some more effort on top of that PR?

[rancid turret]

No, but it’s a trivial change.

[civic yacht]

Awesome, do you have a pointer to the code where I'd need to enable/configure that? Is it just an httpx setting? Just so I can update this PR with it: https://github.com/dagger/dagger/pull/3983

[rancid turret]

I can update your pr later but I sent a pr a while ago with a bunch of refactors. Best to change based on that.

[civic yacht]

Okay I can review your other pr too then

[rancid turret]

That’d be great 👍

[ancient kettle]

I was looking over the buildkit v0.11.0-rc1 release notes: https://github.com/moby/buildkit/releases/tag/v0.11.0-rc1

A couple of things stood out as interesting:

• add build history APIs: https://github.com/moby/buildkit/pull/3294
• Add Evaluate(Ref) Gateway API : https://github.com/moby/buildkit/pull/3137
• And this by our very own @still garnet: cni: set hostname as K8S_POD_NAME: https://github.com/moby/buildkit/pull/3044

@civic yacht @wet mason @still garnet Any others that I missed? Will the build history APIs change anything big for us?

[still garnet]

build history is interesting! hadn't heard of that before

[civic yacht]

There's a chance build history might help us out w/ logging and some of the TODOs mentioned in the PR for it are interesting, specifically the "cache summary"

[still garnet]

i'm just glad to see a new minor release, it's been quite a while. (also the provenance stuff is really interesting)

[civic yacht]

Yeah if anyone asks for SBOM support on dagger it should be a relatively clear path now I think

[ancient kettle]

Glad to hear some of it might be useful for us. SBOM stuff definitely seems like something we could leverage. 🙂

@civic yacht Do you know how BuildHistory is different than SolveStatus?

[civic yacht]

It lets you retrieve the information after the build has completed and also seems like it will support more information (like the cache summary). It actually almost invalidates the need for the shim to collect stdout/stderr, but not quite because the way buildhistory is implemented looks to be a separate boltdb history.db, so I think that'd mean that the stdout/stderr isn't cached (which breaks remote cache imports/exports) and isn't always guaranteed accessible, so it doesn't quite work for our particular use case

I did just realize it might be a relatively straightforward path to supporting retrieval of the stdout/stderr when an exec op fails. Technically there's another existing way we could do that already but it's ugly as heck so this might make that easier

[ancient kettle]

Nice! That'd be sweet!

Good to know re retrieving after a build has completed, etc. Cache Summary sounds useful.

[tepid nova]

FYI @charred lotus discussion of build history ☝️😁

[wild zephyr]

Cache summary would help a lot revamping our current implementation of dagger.cloud 🙏

[tepid nova]

Will the upcoming CLI release coincide with an engine release? And if so, will that new engine release finally supersede the "0.2.36" release which is still listed as the "latest" release on the github repo summary view?

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

[tepid nova]

Random crazy / stupid idea of the day: dagger run eventually adds built-in adapters for Docker Engine and Buildkit, and injects a valid DOCKER_HOST and BUILDKIT_HOST so that all buildkit and docker clients work out of the box 🙂.

Of course this is then picked up recursively by container { WithExec }

[mellow bolt]

Hey 👋 . When I try to go build ./cmd/dagger I've got the following error:

go: -mod may only be set to readonly when in workspace mode, but it is set to "mod"
        Remove the -mod flag to use the default readonly value,
        or set GOWORK=off to disable workspace mode.

Does anyone had the same issue ?

[civic yacht]

Hey 👋 When I try to `go build

[tepid nova]

As of today's releases, what environment variables are used by the different client libraries to bypass auto-install? /cc @civic yacht

Context: we're trying to determine if dagger run is worth releasing at the moment, or if we should wait for everyone to align on the same variables so that it actually has the intended effect

[civic yacht]

DAGGER_HOST and DAGGER_RUNNER_HOST exist today

[civic yacht]

I'd vote to delay dagger run until we've made the switch to DAGGER_SESSION_SOCKET, otherwise that will be a big breaking change.

I also think that DAGGER_SESSION_SOCKET should be coming very soon, it's working on all 3 platforms (including named pipes on windows), biggest thing left is to get my terrible nodejs+python code reviewed by those who know what they're doing in those languages 🙂 https://github.com/dagger/dagger/pull/3983

[tepid nova]

Ok 👍

BTW I still have a round of bikeshedding in me about unix vs tcp @civic yacht unless you told me you're too far along in the implementation and the waste of engineering time would be too great

[civic yacht]

The unix/npipe approach exists and works, switching to tcp+localhost would require figuring out auth which is both a lot of engineering effort and might make the DX benefits of tcp+localhost smaller

So my vote is unchanged on that front

Also, I know I keep bringing this up, but I think it's extremely relevant. We have these two features planned independent of all the above:

1. Dagger-in-dagger (without being hidden behind the scary flag)
2. Proxying of sockets from containers to host (i.e. container unix sock to host tcp)

With those two combined, we'll get a localhost dagger api listener that's safe. You'll still be able to include local dirs and env from the host (by mounting them into the dagger-in-dagger exec) but it will be on an opt-in basis.

[tepid nova]

@civic yacht re: dagger run, we're going to move forward and ship it with $DAGGER_SESSION_URL because it's the only way available way for developers to program Dagger with a vanilla GraphQL client. @hybrid widget is going to write a guide explaining how to wire $DAGGER_SESSION_URL into their graphql client, and wrap their code with dagger run.

@wild zephyr is going to add the random path element to remove the main security issue with that (local port scanning)

Ideally we would have waited for everything to be aligned (including SDKs), but we want to get the GraphQL API out, and we can't do that with at least some way for developers to actually write clients for it.

That means in the very short term, vanilla graphql clients will use a different method from SDKs to establish a session. Obviously we need to resolve soon, but those are pretty distinct development tracks, so the impact on DX is pretty small.

The main downside is that if you try dagger run to wrap a tool using an official SDK, it won't hijack the session as you would expect. But nobody uses dagger run yet, so that's OK

The expectation is that eventually (soon) we'll finalize the design discussion on DSI, dagger run will adopt it, and we'll change the docs for client developers to use it. Ideally we'd keep $DAGGER_SESSION_URL around as a convenience, to avoid breaking early adopters (adding random path now helps make that possible). But if it turns out to be impossible for security or other reasons, breaking it remains an option.

However, I'm still not convinced by the unix socket route, because IMO the DX downsides are not worth it.

[civic yacht]

Okay, my inner paranoia is still hung up on making the URL path include a secret, but as long as it's just dagger run I'll be able to sleep at night.

[still garnet]

@civic yacht is this dead code? https://github.com/dagger/dagger/blob/3642f7fb8f03df3b403652f8454adfebad57bf5a/engine/engine.go#L97 - now that we proxy the runner using the shim/oci-runner instead?

context: i'm wiring up the unix socket forwarding now, and deciding how to change/replace MergedSocketProviders

[civic yacht]

Okay let me know if you want to chat about it more, I really think that the downsides go away with the sandboxed dagger-in-dagger approach which is why I keep bringing that up

[tepid nova]

I confess I don’t fully understand the implications of that. How would a client developer use it?

[still garnet]

host unix socket -> container PR is up, bring your paint: https://github.com/dagger/dagger/pull/4025

[wild zephyr]

@still garnet before merging can we have a quick chat about how this affects the playground? Particularly since people will be a able to mount the docker socket with this and therefore gain root access to the underlying machine

[tepid nova]

@wild zephyr how to you avoid host filesystem access?

[still garnet]

We could put it behind the same disable-host-rw flag (do we use that for playground?)

Or add another flag

[wild zephyr]

Host FS access is easier since it's basically Unix permissions. I can make the user running the engine don't have any access. With the docker socket it's a bit more challenging since the engine needs it to provisión the engine image.

[wild zephyr]

This works I guess 😁

[tepid nova]

@wild zephyr do you use cloak dev today?

[wild zephyr]

dagger listen which is the same thing

[tepid nova]

Great use case for sandboxing then 🙂 Which is what @still garnet was saying I guess

[wild zephyr]

Yep, exactly

[tawny flicker]

has anyone encountered:

$ ./hack/make sdk:go:generate
+++ dirname ./hack/make
++ cd ./hack/..
++ pwd
+ DAGGER_SRC_ROOT=/home/dolanor/src/dagger.new
+ MAGEDIR=/home/dolanor/src/dagger.new/internal/mage
+ cd /home/dolanor/src/dagger.new/internal/mage
+ exec /home/dolanor/src/dagger.new/hack/dev go run main.go -w /home/dolanor/src/dagger.new sdk:go:generate
+++ dirname /home/dolanor/src/dagger.new/hack/dev
++ cd /home/dolanor/src/dagger.new/hack/..
++ pwd
+ DAGGER_SRC_ROOT=/home/dolanor/src/dagger.new
+ MAGEDIR=/home/dolanor/src/dagger.new/internal/mage
+ pushd /home/dolanor/src/dagger.new/internal/mage
~/src/dagger.new/internal/mage ~/src/dagger.new/internal/mage
+ GOWORK=off
+ go run main.go -w /home/dolanor/src/dagger.new engine:dev
Error parsing magefiles: failed to parse directory: /home/dolanor/src/dagger.new/internal/mage/sdk/all.go:35:1: expected declaration, found func
exit status 1

??

[obsidian rover]

declaration not found

[still garnet]

😵‍💫 i had a feeling testing this would be a nightmare, and it was, but it passes! https://github.com/dagger/dagger/pull/4025/files#diff-4ff2fea9232d360a08b025fbeb4080b5f8d80fc69f9251af3f8d3e53fe99ea79

bonus: written entirely in a moving car with rain + wind. glad i don't get carsick

[still garnet]

@civic yacht merged the sockets PR, just pinging since you seemed to have a couple of things waiting on it 🫡

[ancient kettle]

@civic yacht Should your engine bump PR (https://github.com/dagger/dagger/pull/4049) propagate to https://github.com/dagger/dagger-go-sdk automatically?

[civic yacht]

Not yet, we decided to merge the engine version bump for now but not actually do a release of the SDKs quite yet. There are some nodejs changes still pending merge and all else being equal it's preferable to release each SDK version in tandem with out another right now (so there's only one consistent engine version across all of them)

[civic yacht]

"Release of the SDK" is "push a new tag for the sdk version", that's when dagger-go-sdk will be updated

[ancient kettle]

Gotcha! Thanks for clarifying. 🙂

[tepid nova]

dagger listen is hidden right?

[civic yacht]

Yes

[tepid nova]

And dagger session also clearly

That's good 🙂

[obsidian rover]

@civic yacht @still garnet @stray heron could it be possible that we are on a version mismatch between SDKs and engine ? I don't seem to have the socket primitive on latest engine release v0.3.6. I see the primitive on the sdk, but not on graphql API

I can see the withUnixSocket, but cannot use it

[civic yacht]

We didn’t do a release of the SDKs yesterday, just CLI+engine, and I don’t think sockets made it into the engine release (was off by a few minutes). Once nodejs is ready we can do sdk releases along with another engine release

[mellow bolt]

nodejs SDK 0.2.0 has been released today

[obsidian rover]

Ok, so we indeed have an engine / SDK mismatch then (temporary though)

[civic yacht]

Oh okay I didn’t know we were doing it so soon. Whenever we do an SDK release we should also do an engine release right before it, otherwise we end up in situations like this

[mellow bolt]

That's probably something that we need to add into the RELEASING.md (cc @stray heron )

[civic yacht]

Agree, I'll add that to the top as a warning. But also this should be automated somehow. Short of having every sdk run the full test suite of every api, maybe we can do some verification that the schemas are aligned before publishing. Will make an issue

@mellow bolt @obsidian rover https://github.com/dagger/dagger/pull/4064

[mellow bolt]

Thanks @civic yacht 🙂

[civic yacht]

@mellow bolt @obsidian rover @stray heron I think just calling lint as part of publish should safeguard against this in the future, but double check my thinking there: https://github.com/dagger/dagger/pull/4065

[white pilot]

wouldn't this only ensure it's valid against the engine in main, rather than latest release (which is what caused the issue with Node SDK 0.2.0)?

[civic yacht]

Good question but no I think it should work, the CI step that we use for publish calls ./hack/make-prod, which results in it running against whatever the latest released engine is rather than whatever is present in main. So when it lints, it gets the API schema from that latest released engine and checks that the SDK API schema matches

[white pilot]

What's the release plan for the 0.3.7 engine release btw? Is it waiting for these linting changes to make it in?

[civic yacht]

We are figuring out some stuff around the unix socket change and our just released graphql playground, but we're actively working on it and should have the updated engine out soon. Sorry about the delay!

[wet mason]

@civic yacht @still garnet if there's room for it, since we need to release the engine and re-release node, we should include https://github.com/dagger/dagger/pull/3827 (waiting for CI to be green)

[civic yacht]

SGTM

[wet mason]

(someone just complained about it ~1hr ago)

[still garnet]

squash+merging it now!

stepping away for lunch

[white pilot]

Thanks for all your work in getting 0.3.7 out folks ❤️ I assume based on the prior messages that a node SDK bump is also needed to make it all work?

[civic yacht]

Being worked on actively, should be out soon! 🙂

[white pilot]

No worries, just checking that I'm not doing anything wrong on my end 😄

Massive thanks for getting 0.3.7 out, I'll be the first to break it!

[white pilot]

do you know if it's a 20 mins or 2 hours window? Just to know if I should keep my evening coding up or start winding down for the night 😄

[civic yacht]

Haha I'd air on the side of more like 2 hours out of caution (but could be faster if all goes smoothly), I'm finishing up the go sdk release first, will do nodejs next and ping you

[white pilot]

Right, given that I'm supposed to be in a meeting in 9 hours, I should probably call it a night and sort it tomorrow then 😂

though I did just realise I can set DAGGER_HOST in the env and get the node SDK to use that so... maybe just a small experiment

[tepid nova]

fyi that is in flux right now, don’t build anything too long term on that particular feature it will break soon

[white pilot]

my midnight command-line run won't make it into prod, promise

I'm just using it now so I can try the 0.3.7 release to see if my unix socket mount works, without waiting for the SDK release

[tepid nova]

Ah I see, you manually run an engine on the side, then bypass the SDK's default auto-install? Or something else?

[white pilot]

so, I wanna try out 0.3.7. To do that, all I need to do is this

DAGGER_HOST=docker-image://ghcr.io/dagger/engine:v0.3.7@sha256:9ad18aca71b1b1bae137d3ac5b8d1c62bd548d4f3b01c42b48120fdbc1490f22 ./dagger.ts manifests --publish --branch --push --debug

just use the image from the to-be-released SDK

it's a super easy way for me to try out what'll be the 0.2.1 SDK (which just bumps image version) without pulling it down and building on local

it's very much an edge case though, given that this is only happening because of the release issues 😅

[tepid nova]

@civic yacht I got interrupted by lunch & childcare, but working on a reply in the DSI issue.

Short version:

• Agree with summary
• Remaining concern: _PORT vs _URL
• How does dagger session send information to the client (2 values now: json? envfile format? extensibility?)
• I think we may be able to fold dagger listen into dagger session but out of scope for DSI issue, and no rush

[tepid nova]

Got it. Makes sense! Once we're done with the ongoing change, you'll be able to do something equivalent in a more reliable and configurable way, by wrapping your tool with dagger run [VARIOUS COOL FLAGS] ./dagger.ts ...

[white pilot]

makes sense 🚀 love the work y'all are doing ❤️

[tepid nova]

Thanks! Did you see the GraphQL announcement earlier today?

[white pilot]

I did 😄 but you have SDKs in all my favourite languages so presumably I don't need to care much about it? Unless it opens up some cool new opportunities I don't know about yet. Any plans to expose experimental functionality on GQL API and not SDKs (and somehow allow params to the GQL query through the SDK)?

[ancient kettle]

The SDKs have some language specific code, but most of the engine API code is generated directly from the GraphQL, so they should stay in lock-step pretty well.

[tepid nova]

Correct, all SDKs have feature parity with the API. The only gap is if you want to take advantage of cleverness in the GraphQL query language. And of course the playground is fun regardless of what language you use 🙂

That + shell scripts

[civic yacht]

@white pilot https://www.npmjs.com/package/@dagger.io/dagger/v/0.2.1

[white pilot]

Not sure I'm doing anything wrong, and I suspect this might not be a dagger engine issue, but rather a macOS or (more likely) me issue. When using the mounted socket, the connection to the SSH Agent is refusing. Currently just trying to run ssh-add -L to test it. Probably missing something stupid about mounting the socket. Just getting Could not open a connection to your authentication agent.. Mounting my $SSH_AUTH_SOCK to /default.ssh and setting that in the env

[civic yacht]

Hm okay we did run into an issue w/ the unix sock test case on macos, but we were able to successfully use the docker.sock so we went ahead with the release for now: https://github.com/dagger/dagger/issues/4073

I also just remembered we have a separate test case where we actually setup an ssh agent and that passed on macos, so I think it should be basically working.

If you have some node code to share I can try to reproduce too on my mac

[white pilot]

well, my first issue is that my env is messed up

sec, trying one thing here, let's see if it's just my typing that's failed me again

first problem resolved. There's a confusing thing about the node SDK, will share in #node-sdk-dev⬢

Right, ssh-add working now 👍

let's see if my git push works

Right, at this point it's non-mount things for sure, just me being silly about something and not able to get ssh-add to write to known_hosts properly. I'll pick it up tomorrow in the brief moments between meetings. Trying to run mkdir -p ~/.ssh and then write to it with ssh-keyscan but somehow that's a nonexistent directory. But this is 100% me forgetting something about buildkit

Unix socket mount seems to work well as the ssh-add -L worked well

[civic yacht]

Okay that's good to hear, but let us know how the rest of it goes when you have a chance! Will be great to see it all working e2e 🙂

[white pilot]

If you want to give it a try yourself, here's a generic function for git push

export default async (client: Client, repo: DirectoryID) => {
    
    let container = client.container()
        .from('alpine/git')
        .withMountedDirectory('/git', repo)
    
    const sshSocketPath = process.env.SSH_AUTH_SOCK

    if (! sshSocketPath) {
        console.log('No SSH socket path was found, you may not have an ssh-agent running')
    } else {
        const sshSocket = await client.host().unixSocket(sshSocketPath).id()
        container = container
            .withUnixSocket('/default.ssh', sshSocket)
            .withEnvVariable('SSH_AUTH_SOCK', '/default.ssh')
    }
    
    return await container
        .withEntrypoint([])
        .withExec(['mkdir', '-p', '~/.ssh'])
        .withExec(['ash', '-c', 'ssh-keyscan -t rsa gitlab.com >> ~/.ssh/known_hosts'])
        .withExec(['cat', '~/.ssh/known_hosts'])
        // .withExec(['git', 'push', '-u', 'origin'])
        .stdout()
}

The ash -c is just there because I have too few braincells at this hour to remember how I should modify the exec to redirect the output (>> doesn't work as it'd get treated as an argument to ssh-keyscan rather than stdout redirection). I suspect the directory madness is due to a similar thing.

[tepid nova]

Yeah I deal with that a lot, in my case I wanted to pipe the output of one command into another - need a shell to do that

[wet mason]

If you like to live dangerously:

withEnvVarariable("GIT_SSH_COMMAND", "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no")

that will remove the need to create the known_hosts file

[wet mason]

I don't think that's less secure than generating the known_hosts on the fly

Alternatively, you could create a "static" known_hosts with gitlab's key.

There's a container.withNewFile that just landed in Node 0.2.1:

container
  .withNewFile("/root/.ssh/known_hosts", "gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA ...")
  .withExec(["git", "push", ...])

(so glad we added those helpers to container directly, @still garnet @tepid nova)

[tepid nova]

🙂

FYI @still garnet https://github.com/dagger/dagger/issues/4080

[still garnet]

awesome, thanks for organizing this, the table is super useful

[oak sandal]

Does Dagger API internally rely on Dockerfile frontend to interact with Buildkit?
I was looking at attesting resulting artifacts , looks like buildkit supports it now but if I understand correctly, it only supports Dockerfile frontend https://github.com/moby/buildkit/pull/3240

[tepid nova]

@oak sandal no

[civic yacht]

I haven't dove deep into that new feature yet but from what I can tell it's usable outside of dockerfiles. They have a lot of code w/ special integration with the dockerfile frontend but I don't believe it's specific to it

[tepid nova]

Except for the Container.Build action which does use the standard dockerfile frontend

[ancient kettle]

Extensions

[wet mason]

@civic yacht @still garnet Hey ... let's say I want to share some context between graphql resolvers. Any idea on how to do that? I can't stash things in context since child solves won't see that

[civic yacht]

I'll dig up the code I had previously, one sec

[wet mason]

@civic yacht Thanks! I remember that. The catch is I'd like that to be additive (basically what you'd be able to do with context), I believe the solution you had was a global reference table?

But yeah would love to take a look at that code, might be the solution with some extra things on top

[civic yacht]

It is additive, it uses a global reference table because that's all we are given by graphql go, but it creates the end effect of being additive by tracking the state of each path through the graphql queries. Main part is here: https://github.com/sipsma/dagger/blob/da649ddf324bf14800f1863d62453a66b751b651/router/schema.go#L153-L207

Then there's some initialization at the start of the query here: https://github.com/sipsma/dagger/blob/da649ddf324bf14800f1863d62453a66b751b651/router/router.go#L114-L125

[wet mason]

amazing

[civic yacht]

(this is me remembering from a few months ago, so take with grain of salt, but hopefully it's helpful to start ideas if nothing else)

[wild zephyr]

@still garnet @wet mason think I found an engine 🐛 ? https://play.dagger.cloud/playground/-HR9VbIe_6a > this happens in 0.3.6. Not sure if it's currently fixed

[still garnet]

ah, our old friend the scratch panic

not sure if this is the same one that we've investigated, it keeps popping up in new places, and some of them are possibly fixed upstream already, but it kind of feels like whack-a-mole

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

[simple lily]

Would a new Go SDK function to provide an io.Writer be complicated to implement? like func (c Container) WithStdout(w io.Writer) Container

At first I thought it might be fairly easy but then I realized that the Go client isn't actually what's creating the containers so it's quickly sounding a lot more difficult than I originally thought 😂

And since it's generated I'm not sure where I'd begin with that one.

[tepid nova]

Is this for ease of development? Or for efficiency of streaming vs. getting a bulk string?

[simple lily]

My motivation would be to make it easier / cleaner to work with a logger like logrus , as I'd be able to do container = container.WithStdout(logger.WithField("stream", "stdout").Writer()). I figured if it's easy to do then it'd be a nice to have quick change I could push upstream.

it's also be nice to just be able to use stuff like an io.MultiWriter and all the niceties that come with io.Writer.

If not then I can make an issue for it and look at it later

[simple lily]

Also, just noticed this, it seems like whenever a container fails, container.Stdout fails with an error. I'm assuming that's because whenever the container has exited, the stdout file is no longer available. I think using io.Writers here would help since it'd give the caller more ways to handle the stderr / stdout.

I see that I could use WithLogOutput when calling dagger.Connect but that also has a lot of dagger-specific logs I think.

[white pilot]

Q about the execution graph: does Dagger somehow calculate the entire DAG before execution, or is it built out as the execution progresses?

[still garnet]

the entire DAG is built up ahead of time

[tepid nova]

Caveat: with dagger-in-dagger, a node can dynamically add more nodes

But for a given pipeline it’s all built ahead

[white pilot]

Follow-up: can the DAG somehow be retrieved via the API? Ref #general message

[tepid nova]

This is in the context of execution from a CI, right? To not lose step visualization currently offered by your CI?

[white pilot]

Indeed, I'd like to visualise using the DAG

(I realise previous runs might not be persisted so you'd need a persistence layer on top for anything but current jobs)

[tepid nova]

We are at the design phase of solving for this problem, so very interested in understanding your use case & requirements

Would you mind starting a thread in #help for easier linking?

[white pilot]

Sure thing, will do once I get home 👍

[tepid nova]

Actually I can do it for you now to save you time 🙂 will tag you

https://discord.com/channels/707636530424053791/1049373535849693225

[tepid nova]

Heads up, doing some issue & label cleanup

[ancient kettle]

@still garnet I'm looking at this issue + a few associated issues (for NewDirectory, and WithFile, etc). https://github.com/dagger/dagger/issues/3167

Did you have any thoughts/opinions on how you might represent permissions in that API?

[still garnet]

hmm initial thought: stick to Int at the API level so people can use octal syntax in each SDK

octal isn't exactly the most user friendly option but I don't know that we need to reinvent the wheel here, since people are used to it

[ancient kettle]

Yeah, that makes sense to me!

[tepid nova]

YES! Got label list down to one page: https://github.com/dagger/dagger/labels

https://tenor.com/view/sacha-baron-cohen-great-success-yay-gif-4185058

Some labels made sense in theory, but just weren't used diligently enough to be accurate. My approach: better to have no label than a misleading or confusing label. We can always add one later.

[regal fable]

Hello all ! I want to make a PR on the dagger-cue installation script (to fix what I describe in the last lines of this issue: https://github.com/dagger/dagger/issues/4093#issue-1476924855)

But I don't find where is versioned this script. Is it in the dagger repo ?

[obsidian rover]

Hi, I think there has been a mistake. It seems that we merged a dependabot PR that was already in, making it transparent on our history. I believe that your pull action forced pushed your main branch on top of ours. Or am I missing some context @regal fable ?

[obsidian rover]

Oh ok, vikram merged a bump of one of our dependencies. I believe that the PR's name is misleading, changing it. However, you marked #4093 as revolved, I don't understand why

[regal fable]

Yes I didn't describe the context 😁 . So I found 2 issues :

First, a documentation issue here: https://github.com/dagger/dagger/issues/4093

• I've done a PR to fix it
• It was reviewed and merged, so it's done, the GitLab CI example in the doc is now working

But, I noticed as well 2 update/improvements to do in the dagger-cue installation script. This is linked to the issue #4093 but not dependent. So I want to open an issue and a PR about it but I don't know where dagger-cue installation script is stored, so it's my question: where can I find it, what repo?

[obsidian rover]

Ok, regarding the first documentation issue #4093. From my understanding, the PR https://github.com/dagger/dagger/pull/4094 fixes it. However, whenever I go on the PR page, I see 0 files changed... Can you please point me where the change is ? It seems the commit merged is a dependabot one

[regal fable]

Oh, you're right 🤔 ! Let me check, it seems that a force push override my updates

Cannot do it right now, will do in a few hours 😉

[obsidian rover]

It seems to be due from a github bot named pull (that you have on your side?). I'll try to find the answer to the second question during that time 🙏😇 Thanks for helping fix the Gitlab CI example 🙏

[regal fable]

I've disabled this annoying bot and I created a new PR here: https://github.com/dagger/dagger/pull/4108/files (just for the doc update)

[rancid turret]

I see a bunch of my issues that had the cloak label were changed at some point to area/core which isn't accurate (it's only one piece of cloak). So now area/engine has more issues than needed.

[tepid nova]

Yeah area/core and area/engine got very large and noisy. My assumption is that it’s now bloated and needs cleanup & triage anyway.

[civic yacht]

I did a ton of cleanup yesterday, there's still a lot of issue left but they all are relevant to engine now I think.

[tepid nova]

Sorry if I caused confusion, it felt kind of like cleaning a messy fridge in a place with 10 roommates 😛 You know some stuff definitely was forgotten weeks ago, but sometimes it's hard to tell 🙂

[rancid turret]

No, the problem was changing cloak to area/core.

[tepid nova]

I think I might have done that, a few weeks ago (can't remember)

[rancid turret]

All the issues I saw it was Miranda but she might have taken the cue from you 🙂

We'll sort it out, but I feel we need some guidelines on which labels to use. There's a area/sdk and sdk/xxx, when should the first one be used? Then there's some inconsistencies between some area/ and kind/. Things like that.

[tepid nova]

I removed area/sdk it's redundant

In some specific cases, if an issue applies to all SDKs, it's easy enough to just add 3-4 labels

[rancid turret]

Yes, I feel the same way.

[rancid turret]

area/sdk is still there.

[tepid nova]

Oh my mistake. I didn't remove it because of all the codegen-related stuff

Maybe area/codegen?

[rancid turret]

I think we can just remove it. There's two with needs/discussion which means there's no plan of action yet. If there was we could then add the sdk labels that are a part of that plan.

For the others there's already an sdk or engine assigned.

This one could use at least sdk/go: https://github.com/dagger/dagger/issues/3885

[rancid turret]

Sometimes it's unclear if it's an API change (engine), a convention for all SDKs to adopt (codegen) or even still to agree on a solution. Eg., https://github.com/dagger/dagger/issues/3457

[rancid turret]

I cleaned up area/sdk quite a bit. There's 6 remaining issues with it assigned.

[wet mason]

@civic yacht Hey -- there's no way to run a Go SDK app using the dagger CLI yet (e..g through env variables), right?

[civic yacht]

No because dagger run uses the session token stuff. Actively working on updating all that so everything should be in sync soon

[wet mason]

neat

@civic yacht any workaround if I want to take over stdout from the engine?

[civic yacht]

You're using the go sdk and want the engine to send stuff over stdout?

[wet mason]

Trying something with logs, I need to take over stdout. Ideally dagger run --> engine.Start --> pass engine address over to the SDK, and the CLI controls stdout

But since it's not doable right now, trying to find a workaround for that

I could tweak engine session, but it's using stdout for the port

[civic yacht]

The SDK reads logs from the engine over stderr right now, but if you can't use that then you could just pass another pipe to the child process as an extra fd for now

[wet mason]

@civic yacht trying something

[wet mason]

@civic yacht (btw unrelated -- I don't know how much it's worth trying to figure out what's up with our build cache vs just waiting to simplify the engine/cli/build process. Right now it takes a big minute to build a one line change)

[civic yacht]

It takes ~20 seconds on my laptop, not sure if something else changed, but yeah we don't have cache mounts for go build cache, I would suspect that'd help trim it down either way

[wet mason]

even with no changes it's still pretty slow here, weird

[civic yacht]

That seems odd then, with no changes it takes 4 seconds for me

[wet mason]

Mac?

[civic yacht]

Linux

(vm on mac, but my client is in Linux too so mac shouldn't be involved)

[wet mason]

twice in a row (so obvs no changes on second run):

./hack/make engine:dev  2.40s user 2.14s system 10% cpu 43.380 total
./hack/make engine:dev  2.76s user 2.19s system 11% cpu 43.568 total

stashing that into "to be checked at some point" 🙂

[civic yacht]

Oh you should just use ./hack/dev, ./hack/make first builds the dev engine and then runs whatever target you provide, so you are building the dev engine twice. There's some docs here but maybe they need to be more discoverable or clarified: https://github.com/sipsma/dagger/blob/a49e9472056bea007486ac3694a6d606317ea554/hack/README.md#L7-L7

./hack/dev accepts arbitrary args which it will exec (i.e. ./hack/dev go test ... or ./hack/dev bash). It's essentially like a stripped down dagger run but usable by ci without creating chicken-egg loops

[tawny flicker]

It is a problem that we're gonna fix soon'ish

[mellow bolt]

If I try to run node.js SDK v.0.1.1 (latest is 0.3.0), related to this PR (https://github.com/dagger/dagger/issues/3984).

I've got the following error:

yarn run v1.22.19
$ node --loader ts-node/esm ./deploy.ts
(node:22498) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could 
change at any time                                                                                     (Use `node --trace-warnings ...` to show where the warning was created)
file:///Users/slumbering/forks/demo-nodejs-sdk/node_modules/@dagger.io/dagger/dist/provisioning/docker-
provision/image.js:256                                                                                             throw new Error("failed to read port from engine session");
                  ^
Error: failed to read port from engine session
    at DockerImage.<anonymous> (file:///Users/slumbering/forks/demo-nodejs-sdk/node_modules/@dagger.io/
dagger/dist/provisioning/docker-provision/image.js:256:19)                                                 at Generator.next (<anonymous>)
    at fulfilled (file:///Users/slumbering/forks/demo-nodejs-sdk/node_modules/@dagger.io/dagger/dist/pr
ovisioning/docker-provision/image.js:4:58)                                                                 at processTicksAndRejections (node:internal/process/task_queues:96:5)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Do I also need to downgrade my engine version ?

Another question pop up on my mind. As SDKs are evolving side by side with the engine, do we need to warn users that a specific SDK version require a minimum engine version ?

[civic yacht]

The SDKs automatically provision an engine thats compatible w/ their version, so we shouldn't need to warn users about anything right now

[civic yacht]

Not immediately sure why you'd get that, if you enable log output do you see anything else? The error basically means that the session binary failed to start

[mellow bolt]

🤦‍♂️ True... I can see that by browsing sdk by tags. Thanks for the reminder

[civic yacht]

No worries! I'm updating a bunch of details around the engine session stuff right now, but the last task on that list is to document it all more thoroughly so there can be a reference on how it works in the near future, hopefully that'll help

[mellow bolt]

going to check now

[mellow bolt]

Same error after removing container and volumes...

the log output doesn't give me much infos

[wet mason]

@civic yacht 👋 hey, do you happen to know why resolve image config for ... is its own vertex?

[civic yacht]

Yeah it's this line: https://github.com/sipsma/dagger/blob/c2f2ce13cee98f00c4826dccfbe083bf375ee3de/core/container.go#L211-L211

Essentially when we hit the resolver for From we need to grab the image config. Then on the buildkit level I guess it considers that to be a "vertex" too since it's technically doing actual work which can fail and thus show up as an error in progress (hitting a registry to get the config)

It is sort of a pattern breaker in that it's a vertex in the progress but not actual LLB, just a gateway api, but I think most of that buildkit progress code is full of exceptions like that

[wet mason]

dang, yeah

any way to "shove" that into from? I guess progressgroup would be the only way

[civic yacht]

This rang a vague bell and I found this: https://github.com/dagger/dagger/pull/2306

So actually I don't know if we can even use progress groups for that... At least until we fix it upstream. I forget the details of what that would entail but past-me said it should be straightforward, so I hope he was right

[wet mason]

speaking of progress code exceptions, can I bother you for a few mins today? to get an overview

[civic yacht]

Sure I honestly forget a lot about them since it's been a bit but I can refresh myself quickly

[civic yacht]

Okay I'm good whenever today

[wet mason]

ok cool, I can jump on dev audio

if now is a good time

[still garnet]

gonna eavesdrop

[civic yacht]

@wet mason https://github.com/moby/buildkit/issues/2820

[wet mason]

@civic yacht @still garnet Oh, actually, forgot one thing: statuses. Those are basically "logs" for non-loggy vertices? Like, they contain started/completed info, but the vertices already have that.

Also -- there's a current and total field. Any idea on what uses total? Image and Local don't

[still garnet]

i believe that's used for downloading individual image layers

[civic yacht]

Yeah status is used to indicate the start/stop of pulling a layer, also for diffing/merging: https://github.com/sipsma/buildkit/blob/9624ab4710dd1a63453cc028802c9992b9715f3c/cache/refs.go#L1159-L1159

[still garnet]

@wet mason oh here's how I did autoscroll: https://github.com/vito/progrock/blob/739ff265774ee14c4825a075454b1ed567100750/ui/display.go#L309-L316

also feel free to steal the spotify integration 🙃

[wet mason]

@still garnet @civic yacht thoughts on interactive navigation vs displaying a few lines alongside every vertex (a la bk/bass)? I was thinking interactive because of the sheer number of vertices, but inlined is a simpler ui

[civic yacht]

I'd vote for interactive, it seems more useful in general

[still garnet]

+1 - imagining a long test suite that keeps going after the first failure, it'll be nice to be able to scroll up and investigate before the full suite finishes

[ancient kettle]

@wet mason @tepid nova @tawny flicker @civic yacht @still garnet I'd appreciate any thoughts, ideas, feedback on this proposal for a new secrets API: https://github.com/dagger/dagger/issues/3442#issuecomment-1341762993

[wet mason]

Yeah, that was a recurring problem with 0.2 ... 1) it fails 2) re-run everything with "plain" logs

[ancient kettle]

I was just noticed that

type Container {
  withNewDirectory(path: String!): Container!
}

doesn't exist. Should it?

@wet mason @civic yacht @still garnet Thoughts? 👆🏻

[civic yacht]

I think you can accomplish that conveniently today by doing e.g. c.Container().WithDirectory("/path", c.Directory()).

It's different than the desire for withNewFile because we don't have a similar way of initializing a File with some contents (maybe we should add withContents to File actually? separate issue though)

[ancient kettle]

Ok, cool, that makes sense.

I kinda like c.File().WithContents("hello world")

[still garnet]

huh. so apparently if you try to return an int that's > 2147483647 (max int32) you'll get this:

input:1: directory.withNewFile.stat.mode Cannot return null for non-nullable field FileInfo.mode.

which is technically correct behavior per the spec: https://graphql.org/learn/schema/#scalar-types (Int: A signed 32‐bit integer.)

hmm

this means if someone tries to get the size of a file that's > 2.14GB they'll get an error. 🤔 opening an issue (edit: https://github.com/dagger/dagger/issues/4152)

[ancient kettle]

Huh. That's interesting, @still garnet.

I was wondering about custom scalars with the file/folder permissions work I'm doing.

Because... I'd prefer a uint32 or similar for that.

These two cases have me wonder if we should look into creating custom types for them.

[still garnet]

yup, I ran into this error because of bit flags on 'mode' so we'll need some other representation for that at least. alternatively I could extract those bit flags into separate bool fields, at that point mode should be small enough (0777 max I suppose?)

@civic yacht also proposed introducing our own number scalars: https://github.com/dagger/dagger/issues/4152#issuecomment-1344588891

[oak sandal]

I was wondering if it is possible for Dagger to set a QOS on a build as in- this build job is assured/restricted to get a 1cpu, 2GB RAM

Assuming there's a Dagger/Buildkit cluster running and the request is remote

[oak sandal]

I was wondering if it is possible for

[ancient kettle]

@civic yacht @still garnet @wet mason Any tips for reducing the round trip time for running engine tests? ./hack/make engine:test takes a while...

[civic yacht]

Yeah we have a lot of tests (a good thing!). I sometimes run tests in isolation by doing e.g. ./hack/dev go test -v -count=1 -run Test<name of test> $(pwd)/core/integration

[ancient kettle]

Cool! I just tried ./hack/dev zsh, then the go test. That's roughly equivalent, right?

[civic yacht]

Yep, you won't rebuild the engine every time you run go test (have to exit and re-run ./hack/dev zsh for that), but if that works for what you're doing it should speed things up

[ancient kettle]

Awesome! Yeah, right now I'm just iterating on the tests. But I'll remember to pop back out if I change anything in the engine.

Thank you! 🙏🏻

Side note, @still garnet, I'd love to have Stat right about now... I'm testing the permissions code by loading a directory/file I've created with permissions into a container and running ls -l (file|directory name) and checking for substrings like... require.Contains(t, stdout, "rwxrwxrwx")

🙂

[still garnet]

Lol, I did the same for testing WithTimestamps

[ancient kettle]

https://giphy.com/gifs/portlandia-season-7-episode-10-3ohs7QGeVoV5xhULOU

[wet mason]

Yeah, it's pretty slow generally speaking. Hopefully good opportunity to get some visualization on top and figure out what's going on

I have random cache misses I think, but it's hard to spot with everything going on at the same time

[ancient kettle]

@wet mason Yeah, that'd be nice. I know some of it is that I'm asking it to re-run a bunch of stuff that I've already done... some of which probably should be cached... and some of which is totally already cached. But it's still a bit slow to run that whole loop when I just want to check a single test. the ./hack/dev zsh trick worked well.

[ancient kettle]

Added permissions flags for files/folders on the Directory and Container APIs: https://github.com/dagger/dagger/pull/4157

[tepid nova]

@wet mason is there a rough consensus on certain parts of the service API? So that we can rebase our proposals on top of it & not reinvent the wheel.

For example how to actually start it. Something like this?

extend type Container {
  start(...): Service!
}

[wet mason]

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

this is how far I got -- API design what not really a goal of that PR, so take it with a grain of salt

[wet mason]

A tricky bit is starting a service and starting a container have different APIs, in buildkit

[tepid nova]

@wet mason is it useful if I refresh that schema to fit in the current schema (filesystem -> container etc), and incorporate that in my API proposal for container networking?

(currently I just assume service is solved elsewhere, and just "extend type Service")

[wet mason]

yep

[tepid nova]

I am completely brainwashed by @still garnet 's design in bass, now that I am caught up on it. Trying to rebase all networking on top of it, including c2h 🙂

[wet mason]

Yeah I read that a while ago and loved it -- I just don't remember the specifics right now, that's what I keep going back to it

there's some considerations around cache bust, network endpoints need to be "stable" across runs, and bass solved that through some networking in BK stuff

[wet mason]

https://github.com/vito/bass/releases/tag/v0.10.0

[tepid nova]

Basically the trick is to keep hostnames stable (by making them hashes of llb), and be careful to keep IPs out of llb.

as I understand it

If we managed to rebase everything on top of that, the main benefit is that we operate almost entirely at the IP layer, and anything related to tcp/udp ports is lightweight convenience

[tepid nova]

FYI: https://github.com/dagger/dagger/pull/4163

[still garnet]

https://giphy.com/gifs/family-guy-cockroach-good-5tiG8KMfk8h7Dabth8

[civic yacht]

PR to include the (truncated) stdout+stderr from an exec in the error message when it fails, PTAL: https://github.com/dagger/dagger/pull/4161

Should help with the all questions we get around that

[still garnet]

super nice to see that land!

[ancient kettle]

@wet mason @civic yacht @still garnet Can I get some eyes on https://github.com/dagger/dagger/pull/4157 ?

[still garnet]

on it!

[ancient kettle]

🙏🏻

[ancient kettle]

Trying to answer your question about llb.CopyInfo.Mode... and it's not acting how I'd expect. So, I'll probably need to dig in more.

[ancient kettle]

Hmm... I did
./hack/dev zsh
then

$ go test -v -count=1 -run TestDirectoryWithDirectory $(pwd)/core/integration/
=== RUN   TestDirectoryWithDirectory
=== PAUSE TestDirectoryWithDirectory
=== RUN   TestDirectoryWithDirectoryIncludeExclude
=== PAUSE TestDirectoryWithDirectoryIncludeExclude
=== CONT  TestDirectoryWithDirectory
=== CONT  TestDirectoryWithDirectoryIncludeExclude
    suite_test.go:21:
            Error Trace:    /Users/joel/src/dagger-main/core/integration/suite_test.go:21
                                        /Users/joel/src/dagger-main/core/integration/directory_test.go:241
            Error:          Received unexpected error:
                            fork/exec /Users/joel/src/dagger-main/bin/dagger: exec format error
                            Please visit https://dagger.io/help#go for troubleshooting guidance.
            Test:           TestDirectoryWithDirectoryIncludeExclude
=== CONT  TestDirectoryWithDirectory
    suite_test.go:21:
            Error Trace:    /Users/joel/src/dagger-main/core/integration/suite_test.go:21
                                        /Users/joel/src/dagger-main/core/integration/directory_test.go:188
            Error:          Received unexpected error:
                            fork/exec /Users/joel/src/dagger-main/bin/dagger: exec format error
                            Please visit https://dagger.io/help#go for troubleshooting guidance.
            Test:           TestDirectoryWithDirectory
--- FAIL: TestDirectoryWithDirectoryIncludeExclude (0.00s)
--- FAIL: TestDirectoryWithDirectory (0.00s)
FAIL
FAIL    github.com/dagger/dagger/core/integration    0.239s
FAIL

Looks like I've got the linux binary...

/Users/joel/src/dagger-main/bin/dagger: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, Go BuildID=0ZejYqOeuUKaRoC5c0cY/o0S2tEBd6KxpJbq3rCAP/0fTD3xurVvL4nR6IsOPC/T4LK84drh5ktgVzQ4W5_, stripped```

I just rebased on main, and I'm still getting this error. @civic yacht @still garnet. Any ideas why that'd be happening for me?

I removed that binary, redid the ./hack/dev zsh, and got the same binary back.

[civic yacht]

What happens if you execute the binary directly?

[ancient kettle]

$ /Users/joel/src/dagger-main/bin/dagger
zsh: exec format error: /Users/joel/src/dagger-main/bin/dagger

I rebuilt it on my local machine: go build -o ./bin/dagger -ldflags -s ./cmd/dagger

$ file /Users/joel/src/dagger-main/bin/dagger
/Users/joel/src/dagger-main/bin/dagger: Mach-O 64-bit executable arm64

And it's working just fine now.

[civic yacht]

Ohhh I see, you’re on macos, I missed that

[ancient kettle]

Yeah

I'm guessing that engine:dev isn't copying the correct binary over (or something similar).

I'm looking at that now.

[civic yacht]

Yeah I think so, I’ll be at my computer in a few to look too

[ancient kettle]

👍🏻

@civic yacht I changed func DaggerBinary: https://github.com/dagger/dagger/blob/14b7dc6ef2e4d764aaf5206fc8b2b249061b0bec/internal/mage/util/util.go#L121-L125

to

// DaggerBinary returns a compiled dagger binary
func DaggerBinary(c *dagger.Client) *dagger.File {
    return goBase(c).
        WithEnvVariable("GOOS", runtime.GOOS).
        WithEnvVariable("GOARCH", runtime.GOARCH).
        WithExec([]string{"go", "build", "-o", "./bin/dagger", "-ldflags", "-s -w", "./cmd/dagger"}).
        File("./bin/dagger")
}

And that works (on my machine)

But I'm a bit worried/unsure if that will break in other contexts.

[civic yacht]

Awesome, just got on my computer, that's the right thing to do for this line: https://github.com/sipsma/dagger/blob/a795bea02f59a980912cf95e04902b5a77cab39a/internal/mage/engine.go#L226-L226

But in the other contexts we want the current behavior, so we'll need an arg to switch

I can go do that, sorry about the hassle, my devenv is Linux but I normally double check everything on my macos host directly, I just straight up forgot to with that one

[ancient kettle]

No worries!

🙏🏻

[civic yacht]

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

[tepid nova]

Is this a known issue? Getting lots of "failed run" emails on github actions for the last couple days:

[civic yacht]

Oh I guess those must get triggered on every push to main since we push an engine image on every push to main... So in that case the failure is expected temporarily while the SDKs are incompatible with the previously released engine (these tests are meant to run against their default engine dependency, no mocks or local builds). There's a follow up issue for improving these tests here: https://github.com/dagger/dagger/issues/4038

[obsidian rover]

We can de-activate it temporarly, until the follow-up gets in if you want

[civic yacht]

SGTM, I will add re-activating it to the task list for the engine session updates so it's not dropped

[tepid nova]

I'm happy to ignore the emails, I just wanted to make sure it was a known issue

[tepid nova]

Do we really need the hack/make wrapper shell script? It kind of makes it harder to sell the simplicity of "develop your CI as code". See #general where I'm trying to sell it

Also could we move it to a less obscure directory name? Like ./ci instead of ./internal/mage ?

Lastly: the lack of a standardized "loader" is definitely hurting our overall UX. I know our official answer is "wait for extensions", but if there are possible shortcuts to relieve the pain earlier, I'm interested. It's a major gap that is clearly confusing people.

[ancient kettle]

I had some thoughts around this... like using https://github.com/go-enry/go-enry to recognize file types...

so dagger run main.py could identify that you're trying to run a Python program, then try to figure out what the environment should be, maybe load it into a container and run it from there.

There's a decent bit of complexity in that, though...

[tepid nova]

I think for a unified loader to be useful it would need to work at the directory + pipeline name level:

dagger do build --workdir ./frontend

Something like that.

Basically we're talking about bringing back "dagger do" somehow

[ancient kettle]

What would be in ./frontend?

[tepid nova]

If you have to specify main.py, you might as well just run it with python directly, dagger doing that part would just get in the way

[tepid nova]

Whatever dagger do needs to know how to run a pipeline called build 🤷🏻

[ancient kettle]

😆 Thanks for clarifying things.

[tepid nova]

Yeah I have no idea

All I know is that 1) people are confused by the lack of a standard entrypoint, 2) it makes sense that extensions will solve this, but 3) if we can relieve the pain earlier somehow without compromising the long term design, users would probably be very happy

[civic yacht]

It's hard to avoid right now because you need to call go run in the exact right way so that we use the right go.mod (we have a separate one for our ci steps so that we can bootstrap dagger from a stable version). Basically, our CI inherently has to deal with some extra complication of bootstrapping that most users wouldn't have to deal with.

For the loader stuff, I think even a compromise solution from "full-blown extensions" will need some way of turning source code into an invokable API. Don't see any way of avoiding that. We already have the ability to do that with Go+Python from the previous work on extensions. If we backfill nodejs and add the ability to convert the derived API into flags for dagger do, then I think we'd have something usable.

The part of extensions that would be missing is the ability for the code you load to invoke other APIs seamlessly; that requires extension version control (dagger.json) among other things. But for a first step that's okay.

But the two missing pieces of A) code-first schema support for nodejs and B) generating cli flags from derived schema aren't exactly trivial. However they both are things we likely want for full-blown extensions anyways, so they wouldn't be throwaway effort if we're careful

[tepid nova]

Placeholder for the "bring back a standard entrypoint" topic: https://github.com/dagger/dagger/issues/4189

[white pilot]

Is it a known limitation/bug that it's possible to get too long file names from the encoded directories/containers? Get an error from lstat with file name too long

ClientError: lstat /var/lib/buildkit/runc-overlayfs/cachemounts/buildkit1109656980/app/eyJsbGIiOnsiZGVmIjpbIkdvSUNDa2xzYjJOaGJEb3ZMeTlWYzJWeWN5OXNaVzl6YW05aVpYSm5MME52WkdVdmFtOWlhV3hzWVM5aVlXTnJaVzVrTDI5dGJtbGhMMkoxYVd4a0wyRnlaMjh0YldGdWFXWmxjM1J6RWwwS0UyeHZZMkZzTG5Ob1lYSmxaR3RsZVdocGJuUVNSbWh2YzNRNkwxVnpaWEp6TDJ4bGIzTnFiMkpsY21jdlEyOWtaUzlxYjJKcGJHeGhMMkpoWTJ0bGJtUXZiMjF1YVdFdlluVnBiR1F2WVhKbmJ5MXRZVzVwWm1WemRITVNWZ29NYkc5allXd3VkVzVwY1hWbEVrWm9iM04wT2k5VmMyVnljeTlzWlc5emFtOWlaWEpuTDBOdlpHVXZhbTlpYVd4c1lTOWlZV05yWlc1a0wyOXRibWxoTDJKMWFXeGtMMkZ5WjI4dGJXRnVhV1psYzNSeldnQT0iLCJDa2tLUjNOb1lUSTFOam96TlRaaE16azVNakprTXpsak4yVmpOVEkzWVRnNE5ERmtZMlkwWkRFek9UTTVNRGsyTnpGaFpHUTFPRFZtWXpJNFpqa3hNRGMyTm1Kak5XTmtNemt3SWlzU0tRai8vLy8vLy8vLy8vOEJJaHdLQVM4U0FTOGcvLy8vLy8vLy8vLy9BVmovLy8vLy8vLy8vLzhCVWc0S0JXRnliVFkwRWdWc2FXNTFlRm9BIiwiQ2trS1IzTm9ZVEkxTmpwaU9ERTVZVFEyWkRjek16ZzVPV00zWXpjMllqWmtZamRrWmpBeU5qZzVNekEyWTJSaU1UZzFNV0ZqWldNMlpERTNZVEF5WVRRMk1XUTFZVGMxTmpFeCJdLCJtZXRhZGF0YSI6eyJzaGEyNTY6MzU2YTM5OTIyZDM5YzdlYzUyN2E4ODQxZGNmNGQxMzkzOTA5NjcxYWRkNTg1ZmMyOGY5MTA3NjZiYzVjZDM5MCI6eyJjYXBzIjp7InNvdXJjZS5sb2NhbCI6dHJ1ZSwic291cmNlLmxvY2FsLnNoYXJlZGtleWhpbnQiOnRydWUsInNvdXJjZS5sb2NhbC51bmlxdWUiOnRydWV9fSwic2hhMjU2OmI4MTlhNDZkNzMzODk5YzdjNzZiNmRiN2RmMDI2ODkzMDZjZGIxODUxYWNlYzZkMTdhMDJhNDYxZDVhNzU2MTEiOnsiY2FwcyI6eyJmaWxlLmJhc2UiOnRydWV9fSwic2hhMjU2OmUxODE1ZjUyYzk1MzllMzNmODY1ZDU0OTQ4YTk4MDYxNmM1ZjExZjM0MjZlNzc5YTFlZDgzOThiMmY0NWI4M2MiOnsiY2FwcyI6eyJjb25zdHJhaW50cyI6dHJ1ZSwicGxhdGZvcm0iOnRydWV9fX0sIlNvdXJjZSI6eyJsb2NhdGlvbnMiOnsic2hhMjU2OjM1NmEzOTkyMmQzOWM3ZWM1MjdhODg0MWRjZjRkMTM5MzkwOTY3MWFkZDU4NWZjMjhmOTEwNzY2YmM1Y2QzOTAiOnt9LCJzaGEyNTY6YjgxOWE0NmQ3MzM4OTljN2M3NmI2ZGI3ZGYwMjY4OTMwNmNkYjE4NTFhY2VjNmQxN2EwMmE0NjFkNWE3NTYxMSI6e319fX0sImRpciI6IiIsInBsYXRmb3JtIjp7ImFyY2hpdGVjdHVyZSI6ImFybTY0Iiwib3MiOiJsaW51eCJ9fQ==: file name too long

happy to report bug if this is new

[civic yacht]

No that's a new one, a bug report would be great 🙏

[white pilot]

unfortunately I have very little information atm, not entirely sure how to reproduce it

[civic yacht]

I'm pretty sure I know what's happening actually, we use content-addressed IDs for the cache mounts which tend to be pretty long. The problem is that in the particular case of cache mounts, buildkit makes a directory on the filesystem with its name. I'm guessing that we are then hitting the limitation in linux where mount options can't exceed a certain (fairly small size)

[white pilot]

I'm also really confused because this code is doing almost the same thing as another one, mounting a similar directory, running the same command...

any reference on how those content-addressed IDs are created/is there a way for me to verify?

[tepid nova]

Buildkit supports mounting regular files, right? If so, should we expose that? Container { withMountedFile } ?

[civic yacht]

We have that already I think https://github.com/sipsma/dagger/blob/738bbf96b0f896cfeb77473bc25870392706c21b/core/schema/container.graphqls#L94-L94

[tepid nova]

Let me screw on my eyeballs correctly then 😉

of course it was right there in the middle of my screen

sorry

[civic yacht]

No worries, I'm sure I've lost cumulative years of my life missing various lines of code sitting right in front of me 🙂

[tepid nova]

I was looking for cleverness ie. Secret { file } to simplify the API and get rid of withMountedSecret but decided against it, no time for cleverness this week

[wild zephyr]

cries in api ref docs https://docs.dagger.io/api/reference/#definition-Container

[tawny flicker]

I just noticed that the fields are not ordered by name.
Should we generate the docs based on alphabetical order? Should we fix the graphql files to be alphabetically sorted?

[wild zephyr]

yep, docs are generated following the same order defiend in the graphqls files. I'm not sure if alphabetical order would be the best since grouping them by "concern" seems to be very useful (i.e: user, withUser, workDir, withWorkdir, etc)

[tawny flicker]

@wild zephyr In the playground, when we click share, we should select the generated URL directly (for CTRL+C), and have a copy/paste button as well.

[dense dust]

100%, I had to roll back the auto-copying feature because it didn't work properly in Safari (WebKit)

[obsidian rover]

@wild zephyr, I think dagger listen doesn't work for me with current main branch. Is it just me?

[dense dust]

I do go run ./cmd/dagger listen

[wild zephyr]

works here @obsidian rover

[obsidian rover]

My bad, wrong url: it needs /query at the end 😇 🙏

[tepid nova]

The CLI should be printing the full URL, so you can just copy-paste it

Easy to fix

[ancient kettle]

@civic yacht I'm working on https://github.com/dagger/dagger/issues/3574 and was noticing that I'm not sure what all of the frontendopts are for dockerfile.v0. Is there a list of those somewhere?

Looks like these, perhaps: https://github.com/moby/buildkit/blob/v0.10.6/frontend/dockerfile/builder/build.go#L37-L70

[civic yacht]

Yep was just typing out a message to link to that

That's all you get though, no documentation

[ancient kettle]

That seems to be the buildkit way.

[tepid nova]

https://tenor.com/view/seinfeld-soupnazi-nosoup-gif-5441633

[ancient kettle]

😂

[civic yacht]

In fairness, there has been effort in backfilling docs a lot recently, there's just a ton to backfill though: https://github.com/moby/buildkit/tree/master/docs

[ancient kettle]

@wet mason @still garnet @civic yacht I think the answer to this question is "no"... but is there any way to create something like map[string]string{} in GraphQL?

Seems like the closest option will be something like:

type BuildArg {
  name: String!
  value: String!
}
type Container {
  build(context: DirectoryID!, dockerfile: String, buildArgs: [BuildArg!]): Container!
}

[civic yacht]

No there's no maps in the base spec. You can do some stuff with custom scalars to support map-like things, but from when I looked into this in the past it's most common to use a list of k,v pairs, exactly like you are here.
nit: will have to be input BuildArg

[ancient kettle]

Thanks for confirming!

I was just noticing input. 🙏🏻

[wild zephyr]

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

[hasty basin]

Is it same as/similar to this? https://github.com/dagger/dagger/issues/3083

[civic yacht]

Not really, that issue is just for reducing the size of those IDs in general since it makes them annoying to deal with in, e.g., the playground. For that message you linked to, the problem ended up being different: #1052343991238152323 message

[bronze hollow]

Will we be able to set a TTL on specific cache layers / containers?

[tepid nova]

You can inject an env variable in your exec with the current time rounded down to your desired interval 🙂

[bronze hollow]

Will we be able to set a TTL on specific cache layers / containers?

Does BuildKit support this?

That’s a neat idea

For my Pulumi, I want it to drift detect each day

So I can use that trick quite well too force one rebuild per day

Thanks!

Not that I have caching on GHA yet though 😅

But due to no secrets, I’m mostly running locally a few times a day; so this will be very helpful

[tepid nova]

We’re working on fixing that 🙂

[bronze hollow]

💯

The Node SDK is fantastic

Using import.meta.url allows me to grab source dirs like CUE

I don’t think that’s possible with Go

[tepid nova]

? can you show an example? Should all have feature parity

Hope that you can share your experience in a guest blog post soon 😁

[bronze hollow]

Go can’t do it because it doesn’t provide any info for where a bit of code is (to my knowledge)

https://github.com/RawkodeAcademy/RawkodeAcademy/blob/main/dagger/utils/index.ts

I have this utility function I can call from anywhere and get the local path

Definitely a video or blog coming soon

I use it here

https://github.com/RawkodeAcademy/RawkodeAcademy/blob/main/projects/website/dagger.ts

[tepid nova]

Oh I see!

[wild zephyr]

Doesn't runtime.Caller provide this?

[bronze hollow]

It’s not quite the same

Because JS is interpreted, I can use that information to understand where I am in the context of the mono repo

Though if it can work in Go, I’d love to see it

[wild zephyr]

IIUC import.meta.url will return the absolute path to the current node file. Is that correct?

if you have a function like:

_, filePath, _, _ := runtime.Caller(0)
dir := GetSourceDir(filePath)

^ isn't that achieving the same result? 🤔

[bronze hollow]

Depends if you use go run or go build I guess

I guess with go run it’s fine

That maybe makes Go a little more appealing to me, actually

But I’m sticking with TS for now

[wild zephyr]

yeah.. that makes sense.. IDK if distributing a Dagger pipeline binary makes any sense at all.. So far all the go examples and use-cases that we've been using are go run based

[bronze hollow]

The multi arch example suggested otherwise, the docs show it off as a binary

I won’t be surprised if someone builds a DSL and a generic Dagger go tool, or perhaps CUE will become this

It probably wouldn’t be difficult to write adapters for GHA and GL pipelines

[tepid nova]

@bronze hollow don’t forget Dagger can be embedded in a third party tool, like for example bass-lang.org . If you want to write a tool for others to use in their repo, the tricks above don’t work at all

[bronze hollow]

Does Bass use Dagger?

[tepid nova]

Yup as of 0.11 😁 https://twitter.com/alexsuraci/status/1597271337344544768

Alex Suraci (@alexsuraci)

shipped Bass v0.11, now with a @dagger_io runtime!

https://t.co/SBHdBkRVqp

plus a few other goodies :)

Twitter · Nov 28, 2022, 4:48 PM

[bronze hollow]

I love the Lisp/Clojure influence. Very cool that it’s got a Dagger runtime now

[civic yacht]

You can also use embed to include all the source files you want with the actual binary, so then it'd work both with go run and a compiled binary: https://pkg.go.dev/embed. Little more boilerplate-y than the equivalent in nodejs but not too bad

[bronze hollow]

Can't embed if the build definitions aren't there until runtime though

[tepid nova]

@bronze hollow is this in the context of working out the root of a monorepo from workdir?

[bronze hollow]

No, that's all working rather nicely

I'm now building an interactive CLI to execute tasks that are dynamically defined within each project within the monorepo

Once I have something working a bit nicer, I'll record a demo

[tepid nova]

That sounds cool 🙂 I guess I’m trying to understand your constraints so I can look for more solutions for your file access problem, potentially in a language agnostic way

[bronze hollow]

All I want for Christmas is client.makeSecret 🥰

[civic yacht]

For your use case, where do the secrets come from? i.e. are they in files/env vars on the client side, are they created dynamically by your pipelines, etc.

[bronze hollow]

I’m using my Doppler action to fetch secrets, I write them to JSON in a container and decide them

I need a way to mark it as a secret in the engine.

[ancient kettle]

@bronze hollow You can doing this now: https://play.dagger.cloud/playground/HkS7Mpv962T

With a couple big caveats.

1. The id you'll get back includes the plaintext of the secret.
2. Your secret will be in the buildkit cache, not encrypted.

[bronze hollow]

I’ll wait for the next iteration 😅

[ancient kettle]

Your voice here would be awesome: https://github.com/dagger/dagger/pull/4193

[tepid nova]

@bronze hollow forgetting dagger, what’s your go-to method for getting doppler vars? I know they offer a few different available methods.

Fun fact: we are the same YC batch 🙂

[wild zephyr]

Speaking about doppler, found this in the orange site today: https://infisical.com/

[bronze hollow]

They pretty much built their own Doppler, but secrets is something I choose not to host myself 😅

[bronze hollow]

I use doppler run — pulumi up locally or I use ExternalSecrets in-cluster

I toyed with Teller, but it’s too much config

I also write a Pulumi provider to get and write Doppler secrets, as well as my Dagger step

So I’m all Dopplered up

[wild zephyr]

nice! liked the flow. wondering what's the main reason behind using your own task runner vs using scripts in package.json? Is that something you saw other projects also adopting or you came up with it?

[bronze hollow]

I don’t want to have to configure scripts for every package

I just wanna put tasks in a dagger folder and auto discover

Using a scripts approach I’d need the same connect call in each package

Seems a bit redundant. Now I’ve got one connect in my entire mono repo

[wild zephyr]

makes sense since npm scripts are not thought to be monorepo native

[bronze hollow]

My approach works well 😀

My biggest problem now is Dagger printing my Google credentials in a GHA runner when it crashes

I’ll need to add some comments to that MakeSecret issue, but that’s definitely my biggest challenge atm

[wild zephyr]

is that using withSecretVariable?

[bronze hollow]

I can’t use that because I’m fetching the secret in a dagger action

[ancient kettle]

Do you like this pattern? (beyond the fact that it leaves the secret in the cached layers)

[bronze hollow]

I mean, if Dagger supports Doppler out the box and I can provide a project and config for each layer, that would be nice

but for now it's all I've got

I think it's maybe inevitable that Dagger needs to support runtime secrets though, within layers. Whether it's SSM/SecretManager/Pulumi&Terraform outputs - we need a way to mark them as sensitive as early as we can and dynamically

[bronze hollow]

Are Dagger builds reproducible? If I delete the BuildKit container, will the same content addressable layers be created with no changes to local file system and no new remote pulls?

[ancient kettle]

Pretty sure the answer is no, unless you're using pinned base layers. e.g. alpine:3.17.0@sha256:c0d488a800e4127c334ad20d61d7bc21b4097540327217dfab52262adc02380c. We've had some discussions around utilizing source policy/pinning (https://github.com/moby/buildkit/pull/3332) to allow for this, but afaik we haven't implemented any of that yet.

[bronze hollow]

I’ve also just realised I could use the native API locally outside BuildKit

I actually don’t need to run it in a container.

[ancient kettle]

Yes, that's correct. There isn't a way to securely get those secrets into Buildkit yet, however.

Unless you set every secret you'd need as an environment variable before initializing your dagger connection.

And using the host { envVariable ...} API:

query {
  host {
    envVariable(name: "mydopplersecret") {
      secret {
        id
      }
    }
  }
}

[bronze hollow]

I still have the problem that I pull secrets from Pulumi stack outputs, but those are less dangerous if I like them

I’ve leaked my GCP creds like 9 times now 😅

[ancient kettle]

Do you have an example of this? I'm curious to see how it works (and looking over this to try to understand: https://www.pulumi.com/docs/intro/concepts/secrets/)

[bronze hollow]

https://github.com/RawkodeAcademy/RawkodeAcademy/blob/main/dagger/pulumi/scripts/up.sh

At the bottom of this Pulumi up, we export all the outputs as JSON, including secrets.

[ancient kettle]

Thanks! And it looks like you're grabbing those here: https://github.com/RawkodeAcademy/RawkodeAcademy/blob/68d1e82d1b0eea0d39111c1b63628b5962cfc3a4/dagger/pulumi/dagger.ts#L51

[bronze hollow]

Yeah

Is there a better way to do this atm?

[ancient kettle]

Not really

I'm working on it... 🙂

[bronze hollow]

😄

Let me know when you need a guinea pig

[ancient kettle]

You'll be one of the first to know!

Our new architecture makes some of these things trickier...

[bronze hollow]

I guess withSecretVariable doesn't make things secret?

[ancient kettle]

It should if it's a host env variable. But, no, otherwise.

[bronze hollow]

Why does that matter?

So much work in vain 😛

https://github.com/RawkodeAcademy/RawkodeAcademy/commit/aebac9a0be44e6e169ef62ff8957f5120d4f29b3

I do prefer this happening on the host now, but still have the same leaky problem.

[bronze hollow]

^^ this answered my “why does it matter” questions

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

[ancient kettle]

Sorry to hear that. I'm working on this, hoping to get some clarity soon!

[ancient kettle]

Glad to hear that issue clarifies it for you! Feel free to reach with any other questions or ideas!

[bronze hollow]

Thanks for your help. I’m subscribed to everything I need to follow 😀

[wild zephyr]

David, you could get a secret from a file. Would that help in your case? https://play.dagger.cloud/playground/eoVBUVKoq4n

[bronze hollow]

I’ll just wait for proper support, I don’t want to bake in any more workarounds atm

[wild zephyr]

makes sense. I think using the secret from the file was the "official" workaround for these type of use-cases until we flushed out the fully fledged secret management thing.

[wild zephyr]

@civic yacht I was trying to see if there's a way to speed up Buildkit's git op by making it do a --depth=1 clone and couldn't find anything in gitsource (https://github.com/moby/buildkit/blob/master/source/git/gitsource.go) or in the issues. Do you have any thoughts about it?

[civic yacht]

I'm not sure as it's a pretty complex dance to setup the git source, but based on this line I think it might already only ever do depth=1? https://github.com/moby/buildkit/blob/c0e38e194c276a6e619e17a5ee7158e5bf55f5bf/source/git/gitsource.go#L529

[fair ermine]

Quick question about https://github.com/dagger/dagger/tree/main/core/integration
I saw some tests are written as raw Query, other using GoSDK, should we convert everything to the GoSDK?

[civic yacht]

Yeah the raw query tests were written before the Go SDK existed. Rewriting them in the Go SDK would make them easier to maintain but it's not an emergency at all, they work the same. I think it'd be fine to just leave them as is and switch them to use the Go SDK if we ever need to go back update them for any reason

[fair ermine]

Should I open an issue to track this?

[civic yacht]

Probably not worth it IMO, it's more of an ongoing background thing, not something we need to track or complete at any particular time.

[tepid nova]

Is there a canonical issue for the "push to private registry" problem?

[civic yacht]

You found it already but just for the record for others, it's here: https://github.com/dagger/dagger/issues/4217

[wet mason]

@civic yacht Ever tried to return a Query from a schema by any chance when you were working on platforms?

Getting some errors on the stitching side: failed to resolve all type definitions: [Query]

extend type Query {
  group(name: String!): Query!
}

[civic yacht]

Yeah it worked at the time in the old platforms approach

Don't recall doing anything too special, i'll dig up that branch though

[wet mason]

Yeah I thought so. Weird

[wet mason]

If I remove extend, it does work though:

type Query {
  group(name: String!): Query!
}

[civic yacht]

Oh maybe we can't use extend when we're returning Query!? Or maybe we'd need to do something like:

type Query {
}

And then after that empty declaration is made first we can start doing

extend type Query {
  group(name: String!): Query!
}

I didn't use extend here: https://github.com/sipsma/dagger/blob/aecc4324686def905ac78c6fca2d1d10df0717a6/router/root.schema.go#L20-L65

[wet mason]

@civic yacht Tried that with no succeess

[civic yacht]

Seems weird, wouldn't be surprised if it's a graphql-go specific thing. Either way, just leaving out extend for now should work right? Or does it cause other problems?

[wet mason]

Nope yeah it works

Just wanted to see if you managed to get it working without extend, to narrow down the problem

thank you!

[wet mason]

@civic yacht Think I found an easier workaround than sessions to pass stuff around

[civic yacht]

Cool, what's that?

[wet mason]

@civic yacht Same workaround we've been using all along for "IDs" -- we're free to return whatever we want from a resolver, even if it wasn't requested, sub-solvers will get it

type Query struct {
    Context QueryContext
}

type QueryContext struct {
    // Group
    Group Group `json:"group"`
}

For instance, Query.group can do this:

func (s *groupSchema) group(ctx *router.Context, parent *core.Query, args groupArgs) (*core.Query, error) {
    if parent == nil {
        parent = &core.Query{}
    }
    parent.Context.Group = parent.Context.Group.Add(args.Name)
    return parent, nil
}

Then in container(), if you look into parent as a *core.Query, you can get the QueryContext back

I do need top-level solvers directly under Query to deal with QueryContext and shove it into the container/directory ID, it won't work magically on non-direct-solvers

But it's pretty simple -- query can add context and return another query, top-level solvers use the context to forge a container/directory/whatever ID to "burn" the context into the ID so it's sticky

[civic yacht]

Does including the group in the IDs of containers+directories help somewhere? As opposed to just passing it through context or other means? It's not that harmful atm but it will cause problems w/ extensions in that it changes the input ID as thus invalidates the cache for execution. Can ignore that for now but would need to deal with it eventually

[wet mason]

Yeah, because of lazy execution, we need to remember the group when we do LLB ops

[group is here].Container().From("alpine").[group is lost because not in container ID].Exec(...)[no group in llb.Run]

that could have happened over multiple calls (1 / from alpine, get the id 2/ exec). I'm not aware of a better way than ID encoding to remember things

same class of problem as the ID itself, right? if there was a better way, then we wouldn't use LLB itself as a container ID but some ID mapping instead

[civic yacht]

I see yeah that makes sense. We will need to figure something out with extensions so that only parts of the IDs end up being part of the extension cache key. Plenty of options, all ugly, but can make it work.

[wet mason]

WIP PR is out: https://github.com/dagger/dagger/pull/4248

[bronze hollow]

Does Dagger still DAG? I’m looking at all my imperative code with awaits and I don’t really know if Dagger still builds a graph

[obsidian rover]

Your GraphQL is interpreted as a DAG by buildkit, yes. Otherwise, we do not DAG between each GraphQL query

[bronze hollow]

Is it safe to say the majority of build pipelines will never be a graph then, with the new SDKs

This explains why caching is rather broken atm too then?

[obsidian rover]

My (personal) guess is that people will rely on smaller DAGs, without noticing.
As people get more educated, they will be able to construct (willingly) bigger graphs, to fully benefit from parallelization. It's the tradeoff to have a much better DX, and more control at the language level

[obsidian rover]

I don't think it is broken though. Do you have issues ?

[bronze hollow]

If I run the same task twice, it’s fine

If I use a task as a depdendency, it doesn’t cache

[tepid nova]

All that stuff should work the same as it did before, and as you expect, ie: it should cache

[bronze hollow]

https://github.com/RawkodeAcademy/RawkodeAcademy/blob/main/projects/rawkode.cloud/teleport/dagger/deploy.ts

Example. This deploy task depends on the DNS task and the DNS task is cached if I run it on its own but not here

Perhaps it’s some weird issue with my setup

[obsidian rover]

Do you mean that these 2 lines https://github.com/RawkodeAcademy/RawkodeAcademy/blob/a39e287f366bb170fc65285073abe9f597c5833d/projects/rawkode.cloud/teleport/dagger/deploy.ts#L11-L12 get recomputed ?

[tepid nova]

It’s a very common problem to not know why things don’t cache. Or more generally what the DAG is. The good news is that we have sweet tooling coming to help solve this 🙂

I was going to share Andrea’s demo: https://m.youtube.com/watch?v=KfnAfIgWpTw&noapp=1

But it looks like the screenshare is missing? cc @cosmic cove

[bronze hollow]

I’ve been missing the community calls, since working for myself I’ve been slammed. That’s why I posted a CLI demo in this channel with my progress. Hopefully catch the calls again in Jan

I’ll check out that demo. Thank you

[obsidian rover]

I'm currently dreaming of a dagger command to init a "scaffold" of a project, in any of the SDK language. I'm about to make my own tooling for that, not sure if it may fit in Dagger's CLI, but by jumping between languages, there is friction to remember how to init in each language a project

[cosmic cove]

oh no! Ok, working on fixing that asap.

[cosmic cove]

@bronze hollow good to see you again! Here is the proper logging demo link (sorry about that!) cc @tepid novahttps://www.youtube.com/watch?v=bL_9GOCZy3Y

[tepid nova]

@civic yacht maybe a silly question. Has anyone tried using firecracker as a buildkit runner via oci hooks?

[civic yacht]

Not a silly question, that's always been something I've wanted to try. I think the best route would be to have buildkit use its containerd executor backend (instead of the runc backend we use right now). Then you could setup containerd to use either kata containers or firecracker-containerd as the default runtime and that should result in buildkit running containers in firecracker VMs.

I'm not totally sure if it would completely work out of the box. It requires use of the devmapper snapshotter rather than overlayfs, which would result in some overlay-specific optimizations not being available, so it would be slower in some cases. Can't immediately think of anything that would completely break, but there's so many details I'd bet something wouldn't quite work.

In theory it's totally possible though, just might require some upstream tweaks

[wild zephyr]

@civic yacht @tepid nova I recall docker acquiring a runtime company called nestybox which are the ones behind sysbox (https://github.com/nestybox/sysbox) which claims to provide a secure runc compatible runtime which allows running privileged workloads. They specifically advertise a secure sandbox without using VM's. That could be an alternative for a faster integration. Solomon we could ask Justin about it

[wild zephyr]

there's still yet no support for buildkit's cache exports / imports in Dagger SDK's, correct?

[civic yacht]

Not yet, issue+proposal here https://github.com/dagger/dagger/issues/3965

[rancid turret]

Hey @civic yacht 👋 I'm looking at https://github.com/dagger/dagger/pull/4285, I thought dagger session would return port and token, but it's still giving host and token. Is that right?

[civic yacht]

Ah yeah, it's technically not necessary to change that too since that's an internal only interface but it would be more consistent, you're right. I can add a commit with that too

[rancid turret]

Yeah, I think that would be better.

I meant for ConnectParams to reflect the JSON returned there.

Makes things simpler.

[civic yacht]

Pushed a commit with that too now in the go+nodejs code, except for the python sdk code since you were gonna update that anyways

[rancid turret]

Yeah, it's ready 🙂

Just running tests locally, I'll push in a bit.

[rancid turret]

@civic yacht What's the engine failures in CI?

[civic yacht]

Oh I only ran the sdk tests locally, missed an update needed to the engine test, just pushed a fix for it

[rancid turret]

By the way, any idea when next engine release?

Needed for releasing new sdk version.

[civic yacht]

Main blocker is the session related stuff, but PRs are out for everything there, should be merged in next few days. It would also be nice to wait for a v0.11 buildkit release since there's a ton of fixes we've made upstream to various issues, but technically not a blocker. I was just testing out a rebase on their v0.11-rc3 branch to make sure there's no surprises.

I'll make a milestone for v0.3.8 engine release and put stuff in it.

[civic yacht]

https://github.com/dagger/dagger/milestone/16

[rancid turret]

Neat 🙌

[bronze hollow]

Welcome back Dagger team. Happy New Year.

@ancient kettle I'm assuming you finished secrets support instead of taking time off, right ? 😄

[ancient kettle]

😛 We still have some big design decisions to make. I'm hoping to make some time this week with @tepid nova to get on the same page around the DX/OX stuff he's been talking about, and see what the various constraints are in that. I'm also planning on mocking up the various ways I imagine secrets working, so we can get a sense of how it feels in each scenario.

[obsidian rover]

Any idea/hints on why the error message returned from waitBuildkit is being printed several times, when manually running the dagger session? Is it an expected behavior ?

I presume it is in the startCLISession function, but not sure 😕

 _EXPERIMENTAL_DAGGER_RUNNER_HOST=docker-container://test-dagger-engine-toto bin/dagger session
Error: buildkit failed to respond
Usage:
  dagger session [flags]

Flags:
  -h, --help   help for session

Global Flags:
      --debug            show buildkit debug logs
      --workdir string   The host workdir loaded into dagger (default ".")

Error: buildkit failed to respond

With the potential forward of stderr from SDKs, I also realized that the usage printing (due to cobra) this might polute the output ? 😕

[civic yacht]

If you're manually running the session you won't be going through the SDK so startCLISession won't be executed. Not sure immediately why the Error: ... is printed twice, could be something with cobra? Agree that we should skip the usage printing for the session subcommand, I'd suspect there's a way of disabling that in the struct where we configure that subcommand. Maybe try disabling that usage output and see if that also happens to fix the double print of the error message

[obsidian rover]

Thanks 🙏 We fixed the usage with @ancient kettle, works fine. It doesn't fix the double printing though, but we're slowly tracking it down 😇

[civic yacht]

Okay cool, you could try wrapping the error type returned to have an Error method that also prints the stack trace of the caller if stuck

[ancient kettle]

Ok. We figured it out. cobra is printing the error when the subcommand session fails: https://github.com/dagger/dagger/blob/main/cmd/dagger/main.go#L47, then we print it again https://github.com/dagger/dagger/blob/main/cmd/dagger/main.go#L48

@obsidian rover and I verified by silencing errors in the session subcommand changing our printing of line 48 to be Dagger Error:, which caused only Dagger Error: buildkit failed to respond to print.

Any reason we shouldn't just pull our printing of the error?

[civic yacht]

Hm no I think we can just remove our print of the error

[obsidian rover]

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

[tepid nova]

Do we currently support catching exit status of a process? Or is it one of those "harder than it looks" issues? And if the latter: is there an issue tracking it?

[ancient kettle]

Pretty sure this is still a no, and in the category of "harder than it looks", because it requires stuff from the shim, creates potentially weird caching issues, etc. Pretty sure this is the issue tracking it: https://github.com/dagger/dagger/issues/3192

[tepid nova]

Noted, thanks. This is in the context of issue cleanup, there's another issue for the CUE version of this problem, I'll close it since the CUE API is frozen

[obsidian rover]

If anyone can take some time to review https://github.com/dagger/dagger/pull/4284 today 🙏

[obsidian rover]

@civic yacht followed your recommendations. Shall be reviewable again if you have some spare time

[bronze hollow]

Is it possible with container().from() to publish an amd64 image on an M1 mac?

RTFM: https://docs.dagger.io/sdk/go/406009/multiplatform-support/

[hasty basin]

Is there a better way to make these docs findable? Did you end up using search in docs or found them another way?

[bronze hollow]

Search on docs is pretty poor. I was searching for "platform" and got some Go stuff to print the platform and some really old CUE stuff

I didn't find my answer on the docs, I found it on Discord by searching for amd64 😂

Then found the docs when I had enough context to search

[tepid nova]

@bronze hollow that's EXACTLY what happened to me 😄 https://github.com/dagger/dagger/issues/4304

[bronze hollow]

hahaha

I feel a bit less silly now 😄

[tepid nova]

btw @bronze hollow could I trouble you for a +1 on that issue? 🙏

[bronze hollow]

Done

    const secrets = await getSecrets("website", "production", ["FIREBASE_TOKEN"]);

    // Set in the environment to consume as a secret below
    // Required until Dagger can protect me
    process.env["FIREBASE_TOKEN"] = secrets["FIREBASE_TOKEN"];

My latest attempt to stop printing secrets out in GitHub Actions logs, force set them to the environment and use client.host().envVariable().secret().plaintext() further down the task.

Is this going to work? 😅

[ancient kettle]

Yes... but only if you do it before you create the Dagger client. That "locks in" the ENV (because it does an exec under the covers).

[bronze hollow]

Bah

[ancient kettle]

I know... 😦

[bronze hollow]

I'll just need to disable Dagger on GHA for now. Too risky

Hopefully not for too much longer though, right? 😄

[ancient kettle]

Yeah, I understand. It's on my todo list for this week to spend some time/effort pushing forward on better Secrets. @tepid nova We should get on the same page, and figure this out soon.

[bronze hollow]

https://giphy.com/gifs/universalkids-universal-kids-ukidsfam-ukids-kiXmQwK9UQZ8EEYXS6

[ancient kettle]

Wow. Now I have to do it.

That GIF is powerful. Please be responsible with it. 😆

[bronze hollow]

😂

Who's working on caching? I need to send it to them too, then I can retire it

[ancient kettle]

External caching?

[bronze hollow]

GHA caching

Does that still work as intended?

[ancient kettle]

I'm not quite sure what the status of that is... @wet mason @civic yacht @still garnet Can you refresh my memory here?

[civic yacht]

Proposal here: https://github.com/dagger/dagger/issues/3965

Probably will take a bit to figure out a full solution similar to the one described there that's actually integrated with our API. We could consider less ideal+temporary solutions that are quicker too since this request is coming up fairly often now

[tepid nova]

@bronze hollow could you describe your use case & requirements for secrets in a standalone issue please?

Specifically why creating a secret either a) from a container or b) from a static host env variable isn't sufficient?

[bronze hollow]

I tried creating secrets from containers, that isn't supported

[tepid nova]

@bronze hollow I believe it is - here's an example: https://play.dagger.cloud/playground/s13eReSxuy-

[bronze hollow]

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

My issue explains why that won't work, @tepid nova

I COULD make that work, but I'd need to fetch each secret individually and mark it as sensitive, it would be rather cumbersome.

I also prefer the host based approach, after discussing this with @ancient kettle

I need the line "NOT_EXISTS" to work 🙂

const getSecrets = async (
            project: string,
            config: string,
            secrets: string[],
        ): Promise<Record<string, string>> => {
            const queryString = qs.stringify({
                project,
                config,
                include_dynamic_secrets: false,
                secrets: secrets.join(","),
            });

            const dopplerToken = await client
                .host()
                .envVariable("DOPPLER_TOKEN")
                .secret()
                .plaintext();

            const response = await axios.default.get(
                `https://api.doppler.com/v3/configs/config/secrets?${queryString}`,
                {
                    headers: {
                        "Content-Type": "application/json",
                        Accepts: "application/json",
                        authorization: `Bearer ${dopplerToken}`,
                    },
                },
            );

            const fetchedSecrets = response.data as SecretsResponse;
            const records: Record<string, string> = {};

            const secretKeys = Object.keys(fetchedSecrets.secrets);
            secretKeys.forEach((secretKey) => {
                // CURRENT CODE: records[secretKey] = fetchedSecrets.secrets[secretKey].computed;
                //__NOT__EXISTS
                records[secretKey] = dagger.markSensitive(fetchedSecrets.secrets[secretKey].computed);
            });

            return records;
        };

[tepid nova]

@bronze hollow thanks for the issue, that's very helpful. I'll use that as my main channel to discuss your problem, we'll make sure to get you unstuck

However I can't promise that we'll unblock you by fast-tracking the design proposal that you happen to like.

[bronze hollow]

I just share opinions, I trust y'all to build the right APIs

Don't rush anything on my behalf ... but if you can unblock me within the next 5-6 minutes, that would be swell

[tepid nova]

😄

In general I have an overwhelming urge to unblock users as fast as possible. I also have an overwhelming urge to make irreversible API changes as slowly as we can get away with. So as you can imagine I am conflicted right now 🙂

If we can find a way to decouple those two things, it almost certainly will be a better outcome for everyone involved.

[bronze hollow]

Shared some extra context in issue

If I can mark environment variables as secret already, would it be a huge api decision to allow me to call client.makeSecret(“someid”, “secret thing “);?

I guess I don’t understand why this is a large decision atm

[tepid nova]

Because it makes it much harder to add something that we've been wanting to add for a long time, which is swappable secrets backends - which I realize now is almost exactly the feature you use from earthly

[bronze hollow]

Ah

[tepid nova]

So the decision on one is effectively a decision on the other. Which prompts a design debate, which is slow because we are not all aligned on this matter.

This in itself is normal and not a bad thing necessarily. What is bad however is having you stuck on your project. So we want to get you unstuck asap.

[bronze hollow]

Go and Node and the other supported languages already have great support to speak to Vault and secrets backends. That’s an advantage over Earthly

But I guess that comes back to your DX OX chat

[tepid nova]

Yes precisely

[bronze hollow]

Who do we need to put in the wrestling ring to make this decision?

[tepid nova]

btw @bronze hollow have you tried earthly "cloud secrets"? I just saw that's a thing, while browsing their docs prompted by your issue

[bronze hollow]

No. I already trust a company with my secrets. I don’t wanna throw some to another

I like that I can provide my own helper in bash. It’s pretty easy going

[tepid nova]

Yeah it's pretty cool I agree. Where do you store the helpers? Does Earthly specify a directory layout?

[bronze hollow]

No

Let me show you the PR because it’s an undocumented feature

https://github.com/earthly/earthly/pull/1822

You specify any arbitrary binary or script that runs in the host and they handle the BuildKit mount

[tepid nova]

Ah cool, it relies on the PATH

you specify it with this?

global:
    secret_provider: my-thing

which appear to be here: ~/.earthly/config.yml

This is a great feature and almost identical to what I want to do fwiw 🙂

[bronze hollow]

This config works for me. Ship it 🚀

Bonus points if it can be configured in code as a string path or closure

Instead of a random config file

[tepid nova]

(I think you can guess what I'm about to answer 😛 )

[bronze hollow]

secretProvider: string | function(string): string 🥰

[bronze hollow]

“Yes, David. Love it. Give me an hour”

[tepid nova]

Basically moving that config into the code would defeat the purpose of a secrets provider feature, for the same reason Earthly moved it to the config rather than the Earthfile (their equivalent of the pipeline "code")

[wild zephyr]

What about making this a thing in the meantime? We could change the session binary so envVariable updates the session helper variables to send them to the engine?

[bronze hollow]

@tepid nova just to be clear about how their secret provider works: it’s called dynamically every time a job requests access to a secret. It’s not executed once at client build. So Dagger would still need a makeSecret api from host execution.

[tepid nova]

Yes, it's called dynamically. But the call would flow from buildkit straight to the user-specified helper tool, brokered by dagger session (and then back to buildkit). No need for the developer (ie. you) to make any makeSecret call, it's all wired automatically for you

[bronze hollow]

Ah

I’m learning 😀

[tepid nova]

Technically you're right there would still be a makeSecret, but you wouldn't provide the plaintext value, just the key (like studio:mypassword) in your earthly example

in my draft I just put that in a modified secret() query: https://github.com/dagger/dagger/pull/4193/files#diff-2510ad189bb216008f90b8da9ca7086e140ff2691add672fa68ab67c1f92279eR9

[bronze hollow]

Sweet. Hopefully my public builds won’t be too far away 😀

[ancient kettle]

Buildkit v0.11.0! https://github.com/moby/buildkit/releases/tag/v0.11.0

[civic yacht]

I know, several hours after we finished our own release lol

[ancient kettle]

😆 It figures. 😝

[tepid nova]

FYI we have a private channel with buildkit devs, if it helps to coordinate

[civic yacht]

It's not actually a big deal at all, we already upgraded to the v0.11-rc3, we can pick up v0.11 in our next release

[rancid turret]

New Build History API allows listening to events about builds starting and completing, and streaming progress of active builds. New commands buildctl debug monitor, buildctl debug logs and buildctl debug get have been added to use this API. Build records also keep OpenTelemetry traces, provenance attestations, and image manifests if they were created by the build. #3294 #3339 #3440

Is this being used in the new Group API?

[wet mason]

Not at all! Looking into that

@civic yacht are you familiar with those changes?

[civic yacht]

Yes this came up in some other discord threads previously. I looked into them a bit for grabbing stderr of failed commands too. One problem there was that the logs are for the whole build rather than an individual exec

I'm not sure if they would be useful for the logging use case you're working on or not

[wet mason]

The first bits look interesting but not very helpful for us, I think

Build records also keep OpenTelemetry traces,

This one could be useful though

[civic yacht]

Yeah it makes more sense for that use case. Like if we wanted to present users a history of builds we could just grab the traces from them and use that to collect statistics, etc. The histories are stored in the engine state on disk under /var/lib/buildkit, so as long as we retain that we can query the history for the engine

[wet mason]

Yeah. I think if we’re collecting the events as they happen and ship them to cloud then we don’t need to access the ones stores locally in buildkit

[wet mason]

@civic yacht Hey, got some time to chat about our CI within the next hour? Need a sanity check on engine versions (stable/dev) /cc @stray heron

[civic yacht]

Yep I'm good anytime

[wet mason]

thank you! finishing a call

[wet mason]

ok ready now. @stray heron do you want to join as well?

[wet mason]

https://github.com/dagger/dagger/pull/4248 <-- merged!

@civic yacht Can you remind me the latest format to pin to a particular version now that we have S3?

[civic yacht]

_EXPERIMENTAL_DAGGER_RUNNER_HOST=docker-image://ghcr.io/dagger/engine:<tag> will pin the image that's provisioned

[wet mason]

I mean, in addition to the image sha as a runner, I also need to pass a custom binary?