Where do you put your Dagger pipeline

[dawn adder]

personally I've landed on dag since I'm also tired of ci and it seemed like a good balance of short + generic + somewhat justifiable + pretty unambiguous.

[weary marlin]

I have seen people use "ops" for all their automation scripts.

[restive ledge]

I have a discoverability issue with "'dag" (similar to Dagger).

I may be overthinking it, but I want people to be able to find my "ci" code even if they know nothing about Dagger. Since it's just plain code, they should be able to find and fix obvious errors.

"ops" is ... interesting. I wouldn't necessarily discard it, but it has a similar discoverability issue. Also, "ops" is such an overloaded or rather misunderstood term in our world.

Chances are there is no perfect answer or my brain just won't ever let me settle on one. 😄

[dawn adder]

I've liked using hack in the past since it's pretty open-ended and unambiguous, but I mostly associate it with random bash scripts, so haven't used it for Dagger (yet?)

Also, this is a total tangent, but there's a general usability problem with finding CI/automation code pertaining to random files in a repo. For example it's difficult to go from a Dockerfile to the Dagger code that builds it. The best you can really hope for is grepping for paths, but sometimes paths are dynamic, or built like filepath.Join(x, y), etc. It might be nice to let automation code just live anywhere in the repo, so it can live alongside the things it builds, and have a path-based automation dispatching scheme. That's about as far as I've thought about it though. Not sure how much it even helps in this scenario. (hope this doesn't derail)

[restive ledge]

I've liked using hack in the past since it's pretty open-ended and unambiguous, but I mostly associate it with random bash scripts, so haven't used it for Dagger (yet?)
I have that same association as well.

That's actually not totally unheard of. Lot of build systems work that way (Bazel and its clones come to mind). It's a nice idea. However it does make the job of platform engineers who may not have that intimate knowledge of the code base harder. I guess it needs to be a balance. I understand the problem and the desire, but I think we (as an industry) are not really there yet.

[weary marlin]

OMG, that's the theme of my talk tomorrow.
Some of the suggestions I make are:

• consolidating all the ci settings into one file you can call from your code.
• leverage custom error handling so that you can throw exceptions from your ci and handle them with your project's toolchain.