Trying to mitigate a file system issue

Description

The test were failing on the default gitlab runners used by normal gitlab users from https://gitlab.com/username/buildstream that are not pushing directly to https://gitlab.com/BuildStream/buildstream and thus using the special runners.

This was because:

• The cache was sorting objects by time stamp but due to the mtime limitation they all had the same time stamp so when sorted they were not in the correct order.
• When elements were build and then a change made so that the cached item and the change had the same time stamp from mtime then buildstream could not tell that the cached item was older than the change and so could not tell that it needed to be rebuilt.

Changes

This patch adds a sleep to force the mtime values to be different and there for to have the intended behaviour, these are all in the tests as this is fundamentally a issue with the tests rather than with buildstream, although it is a limitation.

Other more complex approaches could be taken if the community thinks the additional time would be well spent.

Related items

This merge request, when approved, will close issue/bug: #484 (closed)

---

I presume the resolution of time on runner is 1 second? So sleeping for a time greater than a unit is forcing a timestamp difference?

added 19 commits

• 14f15fdb...eabc3899 - 18 commits from branch master
• 86f2a29c - Trying to mitigate a mtime granularity braking the cache tests

Compare with previous version

Yep the original issue has some data showing this, #484 (closed) . This could be made more complex to detect the level of granularity and to act appropriately but this seems like a lot of effort for minimal gain.

Seems reasonable to me, especially with the minimal time delta added in the commit & the use-case of contributors using a forkbased workflow before sending MR's

approved this merge request

changed title from expiry.py: Trying to mitigate a file system issue to Trying to mitigate a file system issue

changed the description

Seems fine to me. However I'd add some comments to the sleeps so people know why they're there.

I do not believe this closes #484 (closed) as ideally we would actually fix the limitation in buildstream.

I suggest leaving the issue open and adding a comment noting this temporary fix to the tests.

I'm happy with this. Given this is only adding ~3 seconds to the pipeline, I think that a more sophisticated approach would not be worth the time spent.

resolved all discussions

added 41 commits

• 86f2a29c...bd2b3d8d - 40 commits from branch master
• a541ac1b - Trying to mitigate a mtime granularity braking the cache tests

Compare with previous version

resolved all discussions

added 1 commit

• b31f1ed6 - Trying to mitigate a mtime granularity braking the cache tests

Compare with previous version

approved this merge request

added 19 commits

• b31f1ed6...fa5a59f0 - 18 commits from branch master
• 9efe46c3 - Trying to mitigate a mtime granularity braking the cache tests

Compare with previous version

enabled an automatic merge when the pipeline for 9efe46c3 succeeds

canceled the automatic merge

added 7 commits

• 9efe46c3...ef7810f3 - 6 commits from branch master
• 9b29fafd - Trying to mitigate a mtime granularity braking the cache tests

Compare with previous version