Re: [Release-job-failures] release-post job for openstack/releases failed
zuul@openstack.org wrote:
Build failed.
- tag-releases http://logs.openstack.org/5c/5ce46e390be04b19145d1f316e8283c09abb628d/releas... : POST_FAILURE in 3m 15s - publish-tox-docs-static publish-tox-docs-static : SKIPPED
Issue: ------ All release post-jobs today had a failure in the cleanup phase while cleaning up the signing keys. The 'shred -u ~/.gnupg/*' command fails with: shred: /home/zuul/.gnupg/private-keys-v1.d: failed to open for writing: Is a directory It is likely due to the switch to use bionic hosts for trusted release jobs. Impact: ------- The tagging happens before that failure, so the release itself is not impacted. It does prevent the documentation post-job from running though, so releases.openstack.org is currently out of date. -- Thierry Carrez (ttx)
On 2019-03-14 12:03:58 +0100 (+0100), Thierry Carrez wrote: [...]
All release post-jobs today had a failure in the cleanup phase while cleaning up the signing keys. The 'shred -u ~/.gnupg/*' command fails with:
shred: /home/zuul/.gnupg/private-keys-v1.d: failed to open for writing: Is a directory
It is likely due to the switch to use bionic hosts for trusted release jobs. [...]
That does seem to be the case. A newer GPG version started putting subdirectories there, so our naive glob ceased working. https://review.openstack.org/643328 should fix it. -- Jeremy Stanley
On 2019-03-14 13:35:57 +0000 (+0000), Jeremy Stanley wrote:
On 2019-03-14 12:03:58 +0100 (+0100), Thierry Carrez wrote: [...]
All release post-jobs today had a failure in the cleanup phase while cleaning up the signing keys. The 'shred -u ~/.gnupg/*' command fails with:
shred: /home/zuul/.gnupg/private-keys-v1.d: failed to open for writing: Is a directory
It is likely due to the switch to use bionic hosts for trusted release jobs. [...]
That does seem to be the case. A newer GPG version started putting subdirectories there, so our naive glob ceased working. https://review.openstack.org/643328 should fix it.
And then https://review.openstack.org/643585 was needed to fix the fix. -- Jeremy Stanley
participants (2)
-
Jeremy Stanley
-
Thierry Carrez