sub checks in demo

[arctic moss]

Relevant part of my schema proposal: https://github.com/dagger/dagger/pull/5378/files#diff-3929821133ad5395a51d2e4b5e0065de2bba4de917f6a4c5d52d4a2f3020b817R102

[vital locust]

thanks, I was searching for it but hit ETOOMANYBROWSERTABS 🙂

[arctic moss]

and my imaginary implementation: https://github.com/dagger/dagger/pull/5378/files#diff-42fb89a456403754fd2e35d03ea1eff6f1f90a281450e3a10bad517208bd2b69R45

note that I’m implementing it as a go type that is supposed to implement a dagger.Check interface. How that interface is generated, and how the sdk loads it into a gql resolver, is not something I have spent much thought on 🙂

It just felt like it would be nice to have it work that way

note that it gives me control over when to actually trigger which underlying pipeline

for example in the gotestsum case, the top level check I can resolve statically (there’s always a go test suite). But if the client queries its subchecks, then that will trigger the whole go test suite - no choice since that’s how gotestsum works: gotta run the tests to get a report file

I like that this (imaginary) API lets me control the lifecycle of my checks to that level.

in a future version maybe I find a hidden flag of gotestsum (or weite a custom tool that introspects the go test suite) and I ship an optimization that makes it possible to list those subchecks lazily. then, when I query for the individual result of one test, I could run the pipeline filtering for only that test

or, if the client queries for the result of the top-level gotest check, then I run the whole suite to produce the aggregate result

end of braindump