raising a NonzeroReturnCode when download fails

[erickmartins]

Previously, any failures of omero download when trying to download images (often due to binary permissions not allowing for them) were silent; a final pack would still be produced, only missing the relevant binary files. This PR implements checking return codes for all omero download and omero export operations, and fails/cleans up temp files in case any of them fails.

[erickmartins]

This addresses #77.

[erickmartins]

@joshmoore any suggestions on the best way to test this? I'd need to at the very least restart the test server with new settings and run a second disjoint set of tests, I assume.

[joshmoore]

Hmmm... good question, and interesting use case! And one which wasn't built into omero-test-infra from the start. I'm on a tiny iPad so I'll need to look into this more when I'm back at my desk, but my guess is that having multiple calls to the infrastructure in your GH actions is going to be the easiest way to go. That way you could override the docker-compose with the "bad-downloads" settings.

[erickmartins]

I think this would be relatively easy to do using pytest markers, I'm just struggling right now on how to pass an extra pytest argument all the way into the call at cli-build. My first thought was to just check the value of the POLICY_BINARY_ACCESS, but since cli-build runs under a docker exec that does not pass that as an env variable, my user-space cli-build doesn't have access to that. I'm trying to figure out another way to do it without needed any chances in omero-test-infra - any ideas welcome!

[erickmartins]

ok, I think I found a way: from cli-build I can directly run a omero config get to get the value of omero.policy.binary_access and sort tests based on that. (now I need to actually write tests!)