If there's anything useful in Jubilant's logs that we don't get from juju debug-log (e.g. granular wait state changes?), we could consider dumping those to the disk in the directory specified by --juju-dump-logs (in a separate file -- maybe a single file for the session, rather than the per-model files used for juju debug-log).
One approach to capturing these logs for dumping to disk would be to add a handler to Jubilant's root logger at the start of the session if --juju-dump-logs is specified, and dump to disk at the end of the session.
It would be nice if --juju-dump-logs was the source of truth for where the logs you want to capture with actions/upload-artifact end up, to keep our recommended CI setup simple.
cc @tromai -- I've added the rainy day label preemptively, but if this ends up being in scope for your roadmap work we can close this then.
If there's anything useful in Jubilant's logs that we don't get from
juju debug-log(e.g. granular wait state changes?), we could consider dumping those to the disk in the directory specified by--juju-dump-logs(in a separate file -- maybe a single file for the session, rather than the per-model files used forjuju debug-log).One approach to capturing these logs for dumping to disk would be to add a handler to Jubilant's root logger at the start of the session if
--juju-dump-logsis specified, and dump to disk at the end of the session.It would be nice if
--juju-dump-logswas the source of truth for where the logs you want to capture withactions/upload-artifactend up, to keep our recommended CI setup simple.cc @tromai -- I've added the rainy day label preemptively, but if this ends up being in scope for your roadmap work we can close this then.