On 10/10/2025 11.39, Daniel P. Berrangé wrote:
On Fri, Oct 10, 2025 at 11:32:42AM +0200, Thomas Huth wrote:
From: Thomas Huth <[email protected]>
We are going to remove obsolete assets from the cache, so keep
the time stamps of the assets that we use up-to-date to have a way
to detect stale assets later.
Signed-off-by: Thomas Huth <[email protected]>
---
tests/functional/qemu_test/asset.py | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tests/functional/qemu_test/asset.py
b/tests/functional/qemu_test/asset.py
index 2971a989d1e..251953ed99f 100644
--- a/tests/functional/qemu_test/asset.py
+++ b/tests/functional/qemu_test/asset.py
@@ -10,6 +10,7 @@
import os
import stat
import sys
+import time
import unittest
import urllib.request
from time import sleep
@@ -113,6 +114,11 @@ def _wait_for_other_download(self, tmp_cache_file):
self.log.debug("Time out while waiting for %s!", tmp_cache_file)
raise
+ def _save_time_stamp(self):
+ with open(self.cache_file.with_suffix(".stamp"), 'w',
+ encoding='utf-8') as fh:
+ fh.write(f"{int(time.time())}")
Rather than creating a parallel timestamp file, it feels like we could
just call 'os.utime(self.cache_file)' which will set atime + mtime
to the current timestamp, which we can check later with os.stat().
That was my first idea, too (sorry, I should maybe have mentioned it in the
patch description), but it does not work: In the gitlab CI runners, the
files get re-initialized from the runners cache each time the functional
test job is started, so the atime and mtime is always close to the the
current date there --> we would never expire files in the gitlab CI that way.
Thomas
