#GitHub - bgroupe/dagger-zenith-test
1 messages · Page 1 of 1 (latest)
I have not figured it out yet but one thing I wanted to make sure you were aware of is the --focus=false flag, I find it much easier to understand what is going on when debugging with this flag on.
i.e dagger --focus=false call test
And with this on, it does appear to be kind of working
But looks like its getting burried
Could you help me get a better sense of what you're expecting to see in the output and what you would do with that information after its caught?
oh, was not aware of that flag
I basically did this test because I moved some legacy code over to a module, and have been having some trouble trapping container exec errors and influencing the order of execution. I'm triggering a bunch of testkube runs with the testkube cli and having dagger follow the output. the testkube cli always exits 1 on test failures so I am trying to trap them and execute artifact collection in sequence.
Yeah sorry, all the docs around this are an open secret. We are planning to launch in a little bit and these flags and things will be more obvious in the near future.
Just FYI for now, if you're working with zenith, make sure you have this link handy for the latest and greatest docs: https://docs.dagger.io/zenith/
it was working okay in the legacy setup, but maybe I am not seeing crucial output messages
Relying on the build output to see if its working might be a bit tricky, I ran into this myself in a slightly different use case.
so I am trying to trap them and execute artifact collection in sequence.
Is the ultimate end state here a collection of files that are uploaded somewhere or returned to a local directory?
yes, there is a separate API in testkube to collect artifacts after runs, so the basic sequence is something like:
- trigger a variable number of containers which stream output via the testkube cli
- trigger artifact collection on each test execution with a mounted host directory
- scrape those host directories and use a merge tool to generate a report to send elsewhere
Got it!
I think my use case where I ran into issues when I migrated from classic to zenith was quite similar. I was building a static site and trying to check for the presence of the output files locally. However, this was a bit tricker in zenith and I spent a lot of time trying to get it to work.
Its a lot easier to move the output of a function as a parameter into another function than to get it back to your host.
At the end though I realized that I didn't need those files to be anywhere locally, I needed them to be sent to the end state location.
so my check for "did it work" went from
- files show up locally
to
- files show up in the final location
so going back to your situation, if you want to check if things are working locally I would write a function that returns a file of the generated report and then grab it using the new dagger export command
If you don't actually ever need to grab it locally, then carry on and see the end result in the upstream location.
Either way, it does seem that the catch is working because we can see an error ocurred in the output.
dagger export is not in the docs for some reason, I am checking why. #daggernauts message
But if you want to see how it works you can run dagger export --help inside of your module.
Isn't it dagger download now? And soon to be -o flag?
https://github.com/dagger/dagger/pull/5882
https://github.com/dagger/dagger/pull/6432
It's not easy to keep up with how fast Dagger is changing 😂
Yeah I agree, it is rapidly changing haha.
Dagger download is an alias for export, but to you rpoints its going to be a flag soon.
ok now I see there is a discussion in the main Zenith channel that explains all this. I was still catching up when I responded here haha.
so does this mean that export code that works in legacy pipelines to export to the host like this
dag.container().from("myimage")
...
.directory(srcDir)
.export(hostDir);
no longer works in zenith?
Yes, that code does not work as you would expect it to, but the end result is still possible. It works differently in zenith, in the sense that you need to call dagger export
To elaborate a bit, if you are trying to use some file/directory produced by your pipeline internally to a module you can pass around a *File or *Directory within your module. You can return one of those types from a module function to access it from another module but if you want to download it to your actual host machine you will have to use dagger download on a module function that returns a *File or a *Directory. Hope that make a bit more sense. Soon (I think next release?), instead of doing dagger download you will be able to do something like dagger call mymodule myfunction -o ./myfile to download/export.
Thanks for the elaboration Nipuna, you are spot on here.
ic, thank you for the clarification