#I believe there is a known issue that

1 messages · Page 1 of 1 (latest)

grizzled axle
#

Try this: DAGGER_SESSION_TOKEN=test dagger listen

#

@cyan folio note that you can also do this:

dagger run sh -c "env | grep DAGGER"
#

which means you can do eg:

dagger run sh -c 'curl http://$DAGGER_SESSION_TOKEN:@localhost:$DAGGER_SESSION_PORT/query'
rancid jackal
#

I had the idea that dagger listen used to print the SESSION_TOKEN via stdout after it started in the past. Seems like that doesn't seem to be the case anymore. Setting DAGGER_SESSION_TOKEN explicitly should work indeed

grizzled axle
#

@cyan folio this 👆 will spawn an ephemeral session (same as dagger listen) then execute your specified command with the env variables required to connect to it. When your command exits, the session will be shut down.

grizzled axle
#

you mean disable the need for a token?

#

Unfortunately disabling auth would introduce a security vulnerability. On shared systems, an attacker could scan localhost for open ports, then issue graphql queries on your session

#

The current method is less complicated than it appears. What are you trying to do exactly?

rancid jackal
#

@cyan folio take into account that our official SDK's are not just "raw" graphQL clients of the API. Not sure if what you're exploring is effectively coming up with a c# SDK but if that is the case, I'd strongly recommend saying hi in #1121837200712142878

grizzled axle
#

@cyan folio at first glance the way strawberry shake works will not get you to a generic Dagger SDK, because it does graphql codegen differently

#

Your client will still work though. The dev experience just won’t be comparable to other generated Dagger SDKs. It won’t be exactly writing raw graphql queries either. It will be somewhere in the middle.

grizzled axle
#

No worries, what you propose is the standard in “regular” web-focused graphql ecosystem. It generates a client specific to the client queries you want to send (presumably for a webapp). So 2 different apps calling the same API will make a different set of queries, so if they use a regular codegen tool like strawberry shake, they will get a different generated client library.

What Dagger does is different: our codegen tooling scans the entire schema, server-side, and generates a complete library that exposes all possible queries. So all dagger “apps” (really pipelines) can use the same generated library. The web gql ecosystem doesn’t do this because it’s not always practical. It just happens to be practical for Dagger’s API.