Any good first issues?

[real bolt]

I tested dagger in my project and really loved the idea of having cicd implementation as a code. I am looking to give my contributions to Dagger and just wondering from where to start. I checked issues but there are no “good first issue” labels. Any issue I can pick up as a complete beginner in the repository?

[edgy venture]

Thank you! That is a great question. What kind of contribution would be a good fit for you?

I think there's a "help wanted" label

[real bolt]

There’s one - kind/external-help. Can i start with these?

I am thinking to start with sdk. I know go and java. And later on get into more complex areas

[edgy venture]

@real bolt that's very kind. Yes we used to have more, but did a label cleanup last year and this got lost

One thing you can do is look for a bug to fix that is easy to reproduce and not too hard to fix. Like a "paper cut".

https://github.com/dagger/dagger/issues?q=is%3Aissue state%3Aopen label%3Akind%2Fbug

I will think about good candidates in the meantime

[edgy venture]

Oh, yes that is perfect. I would start with that list 👍

[real bolt]

Thanks for the list. I will start picking up something from it.

[low parcel]

@real bolt shout if you need a hand with anything! yes, all help appreciated ❤️

if you want more context on anything, happy to share, i should be able to help with anything engine + go sdk related

[real bolt]

Sure will reach out to you if i get stuck. Thank you 🙂

[real bolt]

@low parcel I am wondering is there a documentation explaining about the file structure of the project? I am having a hard time setting up the project. All I see is bunch of unrecognized packages and functions. However, they are only in .dagger folders meant for performing operations on rest of the code. I am yet to explore full code. Was able to compile and build a dev cli and run it.

[edgy venture]

@real bolt we use dagger to build dagger.

Try running dagger without argument from the root of the dagger repo

[real bolt]

Thanks @edgy venture , I was able to fix first issue. https://github.com/dagger/dagger/issues/10107. Will raise a pr soon.

[dense birch]

dev instructions are in .dagger/README.md if you haven't found those yet.

other tips regarding layout:

• cmd/dagger/ is the CLI
• cmd/engine/ is the entrypoint for the engine (shipped as a container)
• core/schema/ defines the engine's API, built with the api framework in dagql/. dagger call generate -o . to regenerate client bindings, including the go bindings used by the CLI, after you change the API.
• the other files in core/ contain most of the core logic, assembling pieces from engine/. in my experience if you find yourself wanting to edit engine/buildkit/, you've probably gone too deep (obviously issue-dependent though)
• the go SDK is a little different from all the others, and is used to bootstrap them
• core/integration/ contains the bulk of our tests. there are multiple test styles in there, generally you want to copy the ones that call a go sdk client, not the ones that call the graphql API directly. run these with dagger call test specific --help and it'll take care of rebuilding the engine and CLI for you.
• hack/dev will let you export an engine to docker, and then with-dev dagger will set up PATH to use a cli built by dev. this also lets you run go tests directly like with-dev go test. you can drop yourself into an containerized shell with a built engine & CLI by doing dagger call dev terminal

[lilac ember]

this is actually a good question for an LLM 🙂

I don't think we have this documented anywhere currently

[real bolt]

Thanks for the detailed explanation. This is very helpful

[real bolt]

Another question. I was building the cli after changes using dagger call cli command which was little time consuming during builds. I started the engine locally, and used go commands to build the cli that connected to that locally running engine. Is it the right approach? And are there any options available for setting up a debugger?

[lilac ember]

the engine locally, and used go commands to build the cli that connected to that locally running engine. Is it the right approach?

yes, that works as well.

And are there any options available for setting up a debugger?

I don't think anyone has attached a debugger in the engine yet 🙏

[real bolt]

Okay thanks. I have setup a debugger now with CLI. It can really help in debugging.

[real bolt]

One more question, what is the reason of having a fork of graphql go implementationdagql within the project itself? Is it for long term maintenance of the framework? Or there is some some other reason?

[low parcel]

ah 😛 it's kind of drifted since being just a basic fork

originally, we just needed a few extra bits and pieces

but, it's now become a very opinionated framework, with a lot of improved caching logic

also, we've kept extending it as well, for example, the introspection apis are more powerful than just standard graphql

[real bolt]

got it. Little overwhelming but okay. Still exploring the codebase.

[dense birch]

lol wait is it really a fork? I had no idea

[low parcel]

it started like that i think

cc @rough garden 😛

[rough garden]

it's not a fork

it's a much more opinionated implementation of a graphql server, from scratch, designed for dagger semantics. it started here (should probably archive that repo)

[dense birch]

phew ok that's what i thought (forking here is considerably more deranged than having an alternate graphql impl)

[rough garden]

we had a fork at some point to work around some cruft, but most likely we would have ended up down this path regardless

[dense birch]

our graphql api is also fairly unusual, like it doesn't have normal graphql mutation/get semantics, everything's a get and those gets all represent (cached) function calls and function composition

[rough garden]

yeah, and our IDs are all automated

traditional GraphQL has opaque IDs relying on persistence somewhere

[dense birch]

the automated IDs are they're normally quite the pain in the ass

[rough garden]

and a single ID type

[real bolt]

Okay. I also want to know how to get session token. I am trying to run engine locally and want to call graphql APIs via postman. Major problem is to get the auth token. I used export _EXPERIMENTAL_DAGGER_RUNNER_HOST=tcp://0.0.0.0:1234 and dagger session commands to get the token, however its impossible to copy the long token from it. It just freezes the entire terminal and no operation works. I have to kill the session. I guess a issue already exists related to this. With trial and error, i was able to figure out API needs X-Dagger-Client-Metadata and I was able to construct it. The problem I am encountering now is I am unable to get anything from the API. The server is just not responding and the request keeps loading and loading without a response. A panic was happening due to missing labels. Is working now. Also is there a way to run engine from the local source code instead of downloading image from registry? I want to debug https://github.com/dagger/dagger/issues/9890. I wish to run engine directly by compiling it and attaching a debugger to it.