#GitHub - bgroupe/dagger-zenith-test

1 messages · Page 1 of 1 (latest)

steady coral
#

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?

sweet crag
#

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.

steady coral
#

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/

This page documents an upcoming release of Dagger. This release

sweet crag
#

it was working okay in the legacy setup, but maybe I am not seeing crucial output messages

steady coral
#

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?

sweet crag
#

yes, there is a separate API in testkube to collect artifacts after runs, so the basic sequence is something like:

  1. trigger a variable number of containers which stream output via the testkube cli
  2. trigger artifact collection on each test execution with a mounted host directory
  3. scrape those host directories and use a merge tool to generate a report to send elsewhere
steady coral
#

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

  1. files show up locally

to

  1. 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.

shell reef
steady coral
#

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.

shell reef
#

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.

sweet crag
#

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?

steady coral
#

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

shell reef
#

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.

steady coral
#

Thanks for the elaboration Nipuna, you are spot on here.

sweet crag
#

ic, thank you for the clarification