#🧵 Checks as "rails" 🧵
1 messages · Page 1 of 1 (latest)
We're starting to use dagger check as more than just "check if your code has problems", and as a way to "steer" the user towards a desired outcome in a given workspace:
-
Setup ->
github.com/dagger/setuprelies on checks to guide you towards successful setup -
SDK development ->
github.com/dagger/sdk-sdkrelies on checks to guide you towards respecting the common SDK interface.
My thoughts so far:
-
I love it and I think it will be a killer feature of the platform. red/green as guidance is a powerful UI tool for open-ended problems like learning, onboarding, integrations. Also, even more powerful to guide agents in their loops.
-
I want more polish 🙂 Right now I get a short test name (Example:
sdk-sdk:init-writes-sdk-field), a status (ERROR), and then logs. I would love to provide slightly more structured information to the user: 1) a user-friendly description; a custom failure message (not just dumped in logs); and a custom "fix" guidance. I think having an explicit field describing what to do to fix would be enormous. Basically it's a prompt injection hook at the critical handoff of the user's loop - keeping in mind the user could be an agent.
silently adding <@&946480760016207902>
And specifically pinging @marble oracle @broken viper
Flow for developing a new module:
- Initial setup:
cd my-sdk
git init
dagger install github.com/dagger/sdk-sdk
dagger call sdk-sdk init --name=my-sdk
- Dev loop
dagger check
# follow instructions in failed checks
I love it, but I'd add something else, the ability to also return a directory/file containing reports. For instance junit reports, html reports, etc.
Yes also that 👍
re: JUnit, there's a package now for emitting it as OTel tests, not integrated anywhere yet though: https://github.com/dagger/otel-go/tree/main/junit