-
Notifications
You must be signed in to change notification settings - Fork 305
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
test-remote-gpg-import.sh intermittently failing: Can't check signature: public key not found #2351
Comments
I think this is also a case of the wrong summary being used like in #2245 when the builder is too fast and the previous and current summaries have the same HTTP I bet the following fixes it:
Given there's been a few of these issues, I think we should either add a libtest helper function to wipe cached summaries or add an environment variable in the pull code that skips using the cached summaries. |
Oh, I realized another source of these problems (and why I never see them locally). The pull code will send an |
It's officially undefined. Autobuilders with a lot of RAM probably use tmpfs for speed, autobuilders with less RAM probably use ext4 (or maybe some other "sufficiently Unix" filesystem like btrfs or xfs). If the log says
then I assume that means they're running on something without xattrs? |
Yeah, probably. The "requires full xattr support" message means that either it can't set So, yeah, I'm guessing that some of the builders use a tmpfs on /var/tmp. I'm inclined to think that the best course is to have an environment variable for the pull code that skips caching summaries. By default that's disabled for normal operation, but the test suite would enable it and then the few tests where the caching behavior itself is being tested would disable it again and arrange to make sure that the last modified time is always different for the case when the etag xattr can't be used. |
Several tests generate summaries and then expect to use the generated summary immediately. However, this can cause intermittent test failures when they inadvertantly get a cached summary file. This typically happens when the test is run on a filesystem that doesn't support user extended attributes. In that case, the caching code can only use the last modified time, which only has 1 second granularity. If tests don't carefully manage the summary modification times or the repo cache then they are likely subject to races in some test environments. This introduces an environment variable `OSTREE_SKIP_CACHE` that prevents the repo from using a cache directory. This is enabled by default in tests and disabled for tests that are a explicitly trying to test the caching behavior. Fixes: ostreedev#2313 Fixes: ostreedev#2351
I retried the failed builds and they succeeded, which is consistent with this being a caching bug that doesn't always trigger. |
Seen intermittently on Debian 11 autobuilders with 2021.2 and 2021.1. #2313 mentions a similar-looking failure on Arch Linux.
A log, generated on Debian armhf (ARMv7 EABI hardfloat) using 2021.2 patched with #2350
Full log: https://buildd.debian.org/status/fetch.php?pkg=ostree&arch=armhf&ver=2021.2-1&stamp=1618756886&raw=0
ppc64el seems to have failed in the same way: https://buildd.debian.org/status/fetch.php?pkg=ostree&arch=ppc64el&ver=2021.2-1&stamp=1618756791&raw=0
amd64 had the same failure in 2021.1 but succeeded in 2021.2, so I think this is probably an intermittent bug (race condition?): https://buildd.debian.org/status/fetch.php?pkg=ostree&arch=amd64&ver=2021.1-1&stamp=1618432469&raw=0
The text was updated successfully, but these errors were encountered: