Closed fniephaus closed 3 years ago
Yes, the problem are UUID's. The UUID implementation is clock based, so the first 8 bytes are taken from the system clock. If the test runs fast enough, that value will not have changed yet.
There are a couple of different ways to fix this, e.g. "fixing" the test by introducing a delay, using more than 8 bytes for the Travis ID, copy the 4 bytes from the end of the UUID, which is random... What would you like? Ideally, we would just use full UUID's, IMO.
Copying from the end of the UUID sounds good for now. I don't like "random" delays in tests. And I remember that these Travis IDs are supposed to be short, otherwise the UI bails. Could you propose a PR?
Sure. Might not be today though.
There's no rush! Wouldn't have time to review and merge it today anyway ;)
Test failures are no longer ignored in Windows: https://github.com/hpi-swa/smalltalkCI/commit/46e8d5fb8e9239760f9e180c3c2aad507b38be29.
smalltalkCI currently ignores failures for Pharo (and Moose) on Windows. If it doesn't ignore them, we get a couple of test failures:
If someone with access to a Windows machine could have look, that'd be great. There may be an issue with UUIDs?