#I do wish to avoid rebuilding it if the
1 messages · Page 1 of 1 (latest)
Maybe chaining is the right answer, otherwise build if called alone? func (s *SmokeTest) Run( ctx context.Context, wasmBinary *dagger.File, ) (string, error) { if wasmBinary == nil { var err error wasmBinary, err = s.BuildWASM(ctx) ...
Yeah, I think what you want does not require cache volumes. You just want "regular" caching which is something that you get for free just by running the container and returning files or directories from it.
Then you just chain function calls, ie. pass that built (and properly cached) file to another function, and so on
"cache volumes" is a confusing name, that's on us..
I'm seeing a lot of re-executions, though. (apt-get update, etc.) Even when I haven't changed anything in the source directory.
Do you have a dagger cloud trace url by any chance? I'm happy to take alook
I wonder what's changing to prevent the cache from making the second runs almost instant
I don't, $job says we're not supposed do that, unfortunately.
Appreciate the offer!
@distant ether another way to investigate, is to dagger -E call ... then when the run completes, you will stay in the TUI, and you can navigate the trace
I've been doing a lot of that. What shoudl I look for?
A typical cause of invalidation is uploading a local directory with insufficient filtering
You can look for operations that are cached vs. not
Do you have any of those?
Also if you want to share code snippets, I'm happy to look at that
I do see many $ ops, yes. I just realized my filter was including... build output by accident 
// +ignore=[
// "*",
//
// "!.git",
// "!**/.gitignore",
// "!**/.gitmodules",
//
// "!go.mod",
// "!go.sum",
// "!**/*.go",
Removed the offending line // "!**/main.wasm"
Hope that'll work better.
We do have a blind spot in troubleshooting cache invalidation caused by local file upload
@pliant flame is working on something there
Yeah, nice. It would be handy to see what changed since the last dagger call of the same name
@distant ether invalidation issue gone?
I now find myself deep in a chaining refactor. Let me stash and see...
Yes! Filtering out that main.wasm output I'm getting cached layers now
Heck yes. Thank you for the pro tip.
Another valuable tip (which we should really make more obvious) is that you can add fields to your own object types, and then you can chain from your own type
Dagger will automatically persist the state of your object as it flows across the chain. Basically you can create custom artifact types of arbitrary complexity, composed from the primitive types Directory, File, Container, Secret, Service etc
Yep, I am doing that right now. Finally figured that one out in the last day or so and it has made a lot of things make more sense.
A pattern that's working is to create a type that embeds one dagger type and that works for both output and chaining
We should really place that pattern front and center, like actually include it in the generated boilerplate...
I haven't quite figured out the interface thing yet. I'd like to and I have a feeling it would unlock something for me
I did writ ethis helper, which seems like it improves output for the TUI, so it is a bit more like dots ```
// execOutput transforms (out string, err error) from WithExec() calls to display more helpul terminal output.
//
// When err is a [dagger.ExecError], execOutput returns a string containing
// error output and the original error. Example of handling
// dagger.Container.WithExec() output and error in code:
//
// out, err := execOutput(ctr.WithExec([]string{"curl", "cheat.sh"}))
// if err != nil {
// return out, err
// }
func execOutput(out string, err error) (string, error) {
var e *dagger.ExecError
if errors.As(err, &e) {
return fmt.Sprintf("%s: exit code %d\n%s\n%s", e.Cmd, e.ExitCode, e.Stdout, e.Stderr), err
}
return out, err
}