-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vim.fault.FileNotFound during begin.py #66
Comments
This happens every so often it seems:
|
The log file gets created as part of the construct the moment that dom0's runner.py is executed (via RPC from the sd-dev in begin.py). This therefore means the sd-dev's begin.py probably didn't even get as far as triggering the RPC policy (or the RPC request failed somehow). In other words, the 'File Not Found' is merely the naive attempt to fetch the log after the execution finished, and if it didn't exist, it means it probably never even ran runner.py on the dom0. The most likely scenario is that something before that step failed. The main steps in begin.py that precede the call to the RPC policy, involve:
My gut instinct tells me it's probably an intermittent failure connecting to Github in one of those two steps. The journalctl on the sd-dev would probably tell us more (or, say, the absence of the cloned repo in the sd-dev VM as a tell-tale sign that the clone failed) We can hopefully reduce the chance of network interference by reducing the number of network requests we have to make: a) Moving the commit status stuff to the webhook, so it at least happens much earlier, and maybe even just the one commit status 'running' rather than 'pending', to reduce the chance of a failure (#63) b) Perhaps we can somehow copy the codebase into dom0/sd-dev rather than have sd-dev clone it again, since we already clone it on the bastion to inspect the yaml file to learn the Qubes version. I'm not sure how hard it is to copy a folder and its contents via the VMware API, but we could certainly just tarball it up and extract on the other side. But this is all just a theory.. unfortunately, these things seem to happen when I'm not around, and by the time I am, it's too late to check the Qubes VM to see if things like the cloned git repo exist in the sd-dev VM, as it'll have been restored from snapshot for another CI run :( |
(corresponds to freedomofpress/securedrop-workstation@9ee0686)
The text was updated successfully, but these errors were encountered: