Dagger CLI 🧵

[zealous marsh]

We have several inter-dependent questions that need an answer

1. What will the new dagger CLI look like? What commands, flags etc

2. How will we transition from pre-cloak to post-cloak CLI?

3. What’s needed for a great Bash DX? (running Dagger pipelines from a bash script)

4. Is our current investment in solving the above 👆adequate given the importance?

[granite sonnet]

I'm reaching my maximum concurrent thread limit so I will look again later but assorted thoughts:

What’s needed for a great Bash DX? (running Dagger pipelines from a bash script)
@candid gust started a discussion or issue somewhere about this. I can't immediately find it though. I agreed with his ideas though, probably good to continue conversation there.

I also have seen a few different people try out graphqurl with dagger, which was really cool. Something to take inspiration from. It's almost like the command-line version of the playground (almost): https://github.com/hasura/graphqurl

4. Is our current investment in solving the above 👆adequate given the importance?
   Depends on how much we want to (in the immediate term) emphasize the Bash SDK vs. embedding in scripts of other languages (i.e. js, go, etc.). Right now someone is often (but not always) better off using a different language and then calling that script from bash rather than trying to call things directly with bash. We need to fix that in the long-run, but I'm not sure if it's a "hair-on-fire" problem (relative to what everyone else is working on)

[zealous marsh]

bash is in fact a hair on fire problem based on how frequently it comes up as the favorite scripting option

in fact that is what motivated me to start this thread today, someone asked a couple hours ago

[granite sonnet]

I see, yeah in that case then it's in need of someone to work on it. I'd probably put it below the xdx work and the new API still in terms of priorities, but if it's coming up that frequently then yeah we need to figure it out asap

[zealous marsh]

What I’m thinking is that we could perhaps get a good enough Bash DX simply by making the CLI easy to script

[granite sonnet]

Oh totally, there shouldn't be much of a difference at all between the two

[zealous marsh]

That would buy us time to explore more exotic options

Well I’ve seen ideas like:

• Embed a shell inside dagger cli, making it itself a shell
• A full blown Bash SDK that generates bash functions to source in your script

Those are interesting but in this scenario we would move them to the “discuss later” column

[granite sonnet]

Agreed, I found @candid gust post, it's along those lines I think: https://github.com/dagger/dagger/issues/3065#issuecomment-1258100920

[zealous marsh]

Right that’s where I saw the first idea

[candid gust]

my second (simple) proposal here Solomon https://github.com/dagger/dagger/issues/3065#issuecomment-1258100920 could be a good place to start exploring.

I wasn't suggesting to embed a shell per-se, but the actually "wrap" the one that the user is using and handle the engine setup ourselves.

In my head the DX that we should try to simplify now is:

• How do I handle engine lifecycle (start mainly) automatically in my scripts?
• How do I simply write queries and parse their outputs?

Another option that I don't see a lot of people using (probably because they don't know it exists) is defining all their graphql operations in file and then using the -f flag in the CLI. Using this approach with my previous proposal , @rough maple's example here #maintainers message would en up being something like:

---queries.gql---
query Build {
  core {
    git(remote: "https://github.com/dagger/todoapp", ref: "cloak") {
      yarn(runArgs: "build") {
        id
      }
    }
  }
}

query Deploy($contents: String!, $token: SecretID!) {
  netlify {
    deploy(
      contents: $contents,
      token: $token,
      siteName: "jeremy-foo",
      subdir: "build",
    ) {
      deployURL
    }
  }
}

#!/bin/cloak shell #Initializes cloak and injects some generic helper functions

# the --filter term comes from `jq`

RUN="cloak do -f ./queries.gql"

CONTENTS=$($RUN --filter '.core.git.yarn.id' Build)

URL=$($RUN --set "contents=$CONTENTS" --secret "token=$TOKEN" --filter '.netlify.deploy.deployURL' Deploy)
echo $URL

[candid gust]

I do personally prefer using this last approach mostly because:

• Leverage proper IDE features to write queries
• Forces you to have "cleaner" queries since you can't use interpolation
• You could potentially try your queries in graphiql and the playground easier since it's just copy/paste the queries file
• Refactoring your pipelines is safer and easier because for item #1
• Bash script is shorter and cleaner

[zealous marsh]

@lethal torrent this thread 🙂 See 4 points on top

[rough maple]

Super half-baked...
Was playing just now with idea based on this for interactive shell session too...might leave this as exercise for the user, but could be a great way to turn some queries figured out in the playground or samples (saved to a file) and then built into a script:

$ cloak shell -i
Choose your query file:
** -> Local: queries.gql **
   -> Remote: <provide git url>
   -> Cloud: <queries stored in your Dagger Cloud account>
   -> Examples: <try a Dagger query!>


**Local: queries.gql**
Which query to run first?
** -> Build **
   -> Deploy

**Query: Build**
Save results in variable: ___ (BUILD_OUTPUT)

**BUILD_OUTPUT:**
{
  "data": {
    "core": {
      "git": {
        "yarn": {
          "id": "eyJmcyI6eyJkZWYiOlsiR2k0S0..."
        }
      }
    }
  }
}
**Captured: FSID: "data.core.git.yarn.id" in BUILD_OUTPUT_ID**

[zealous marsh]

This is an interesting idea (I like query files and feel we can do more with them) but we should discuss it as a language-agnostic change. Either we introduce this pattern in all languages, or we don't IMO