providers:checkbox: base64 encode binary attachments

This patch changes the following attachment jobs: firmware/fwts_desktop_diagnosis_results.log firmware/fwts_desktop_diagnosis_results_hwe.log installer_bootchart.tgz power-management/poweroff-log-attach power-management/reboot-log-attach stress/graphics-tarball stress/poweroff_30_check_log stress/poweroff_30_log stress/poweroff_check_log stress/poweroff_log stress/reboot_30_check_log stress/reboot_30_log stress/reboot_check_log stress/reboot_log suspend/xrandr_screens_after_suspend.tar.gz In addition, the following local job, which generates attachment jobs, is also changed: suspend/xrandr_screens_after_suspend.tar.gz There are several changes applied here. First, for jobs that use this, the test condition is changed from -e to -f. The rest of the code won't cope with non-file input so it's better to be explicit. While it might, perhaps, be better for those jobs to fail, the condition is there because there is no explicit dependency (because we want to attach log files even if, or especially when, the related non-attachment job fails. The most important change is the way those two attachment jobs operate. Instead of compressing the file and then dumping the binary, compressed data each of the log files is compressed on the fly (to stdout) and base64 encoded. This makes the job re-runnable (as the original log file is no longer removed by gzip) and, most importantly, the output is always valid ASCII text. This should address the issue where those attachments would just end up being empty in the submission. As a small detail, to ensure that the errors are propagated a bash-specific 'pipefail' option is enabled. This lets simple constructs such as: tar cvz /path/to/some/things | base64 Behave correctly when tar fails for any reason. This change was only made to jobs that don't already use the [ -f ... ] && construct as it seems not to be needed there. Fixes: https://bugs.launchpad.net/plainbox-provider-checkbox/+bug/1479648 Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> 

0 files changed, 0 insertions, 0 deletions