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
Seemingly random CI failures of tests/test_intl.py::test_gettext_dont_rebuild_mo
with Windows
#11232
Comments
Yep, I've noticed this occur a few times too. Most recently here: https://github.com/sphinx-doc/sphinx/actions/runs/5006348520/jobs/8971510673?pr=11426#step:5:1930 (taking a brief look at the relevant tests/code) |
So:
The remaining items contain two I think it's unlikely that the In summary: My best guess at the moment is that we're running into a filesystem timestamp consistency issue on some of the runners: sphinx/sphinx/builders/__init__.py Lines 498 to 503 in d3c91f9
And in terms of how to fix that, for test stability purposes: Not sure yet. |
It's tricky without having a way to replicate the problem reliably, but I'd like to try reverting the I've read one or two bugs on the cPython bugtracker that seem to indicate that Windows timestamp granularity had some issues and has been improved since 718993a was introduced - and also I think it's probably relatively rare for people to be building Sphinx documentation on low-timestamp-granularity filesystems (particularly FAT32). So I'm thinking of it as a potential tradeoff between unit test stability and (perhaps) some rare edge cases. |
Update: reverting 718993a does not fix the problem. For a situation where that commit is reverted and yet the test still fails (after a few previous successful test results), see here: https://github.com/jayaddison/sphinx/actions/runs/5038386691/jobs/9035841524?pr=3#step:5:1931 |
I've added some debug printout code, and here is the output from it during a recent unit test run where the failure occurred:
|
…s seen for sphinx-doc#11232) and run a broader matrix of Python versions
This is based on a small sample size so far, but switching to use integer nanosecond-precision timestamps instead of the existing floating-point second-precision timestamps may be helping. If that remains true after a few more rounds of testing, then I'll open a fix pr for this issue, containing the revert of 718993a and the nanosecond-timestamp switchover. |
…iness was seen for sphinx-doc#11232) and run a broader matrix of Python versions" This reverts commit 647df0a.
This comment was marked as resolved.
This comment was marked as resolved.
Because the additional informational logging added for this test failure points to the byte-order-mark ( Perhaps adding further information to indicate whether that test code logic is evaluated could confirm whether it has a causal relationship with the test failures. |
What do you think about adding a debug print between these lines to determine whether that's a potential cause, @AA-Turner? (I've drafted a commit for that at jayaddison@5924a4d ) |
Taking another look at this currently; I'm going to repeat-run CI on my fork with 5924a4d in place to see whether that helps to track anything down. |
…g only occurs on windows Ref: sphinx-doc#11232
This build job failed and the additional output was:
I'm not sure yet whether that helps trace this down. I'm trying to refresh my context about how all this works. |
Does anyone have any thoughts on whether we could/should mark this test as |
We have strict xfail turned on, so that would introduce stochastic failures in the other direction, unhelpfully. A |
Ok - although that only changes the default, I think - so we could specify I'll admit to likely truth of: it's the kind of bug/issue that once hidden, might not really be fixed later (or not until 'much, much' later at least). (subtle, possibly complicated, potentially time-consuming to track down, and seemingly low-impact in terms of production usage (although arguably important for continuous integration reporting)) |
Fixed in #11940 |
Describe the bug
I am (edit: not) competent to understand seemingly occasional:
which I have observed a number of times recently either on PRs or direct pushes to master.
How to Reproduce
See https://github.com/sphinx-doc/sphinx/actions/runs/4383723023/jobs/7674313285 or earlier failed test of #11224 prior to merge to master: https://github.com/sphinx-doc/sphinx/actions/runs/4354037120/jobs/7608843307
As this seems random, I have no recipe for reproducing.
Environment Information
Sphinx extensions
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: