Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upTestTargetScrapeTimeout is flaky #830
Comments
This comment has been minimized.
This comment has been minimized.
|
Full make output:
|
This comment has been minimized.
This comment has been minimized.
|
I've seen this a few times on travis. I assumed it was due to travis being unreasonably slow once in a while as I've never seen it on any of my machines. #832 doubles the timeout - maybe you can checkout the branch and report back whether this solves the problem for you. |
This comment has been minimized.
This comment has been minimized.
|
@fabxc That seems to fix it for me (of course one can never be sure with this sort of thing, but I would've expected to have seen it within the 5 times I tried, since it had been affecting 4 out of 5 builds previously) |
This comment has been minimized.
This comment has been minimized.
|
Fixed in #832 |
fabxc
closed this
Jun 25, 2015
simonpasquier
pushed a commit
to simonpasquier/prometheus
that referenced
this issue
Oct 12, 2017
This comment has been minimized.
This comment has been minimized.
lock
bot
commented
Mar 24, 2019
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
swsnider commentedJun 23, 2015
When running a build from a completely clean copy of HEAD(cc18191), except for a patch that comments out the humanizeTimestamp test from #829, the TestTargetScrapeTimeout test fails often, but not always, when running 'make'.
failing run: