Skip to content
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

[CI] NodeStatsMonitoringDocTests#testToUTC fails #38359

Closed
cbuescher opened this issue Feb 4, 2019 · 4 comments · Fixed by #38610
Closed

[CI] NodeStatsMonitoringDocTests#testToUTC fails #38359

cbuescher opened this issue Feb 4, 2019 · 4 comments · Fixed by #38610
Labels

Comments

@cbuescher
Copy link
Member

cbuescher commented Feb 4, 2019

Build: https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+intake/1812/console

Couldn't reproduce locally but looks like a date formatting issue.

./gradlew :x-pack:plugin:monitoring:unitTest \
  -Dtests.seed=1B6F728E6033F9E8 \
  -Dtests.class=org.elasticsearch.xpack.monitoring.collector.node.NodeStatsMonitoringDocTests \
  -Dtests.method="testToUTC" \
  -Dtests.security.manager=true \
  -Dtests.locale=lv-LV \
  -Dtests.timezone=GMT0 \
  -Dcompiler.java=11 \
  -Druntime.java=8
org.junit.ComparisonFailure: expected:<2019-02-04T16:31:46[]Z> but was:<2019-02-04T16:31:46[.000]Z>
	at __randomizedtesting.SeedInfo.seed([1B6F728E6033F9E8:F583DD13D392E2A0]:0)
	at org.junit.Assert.assertEquals(Assert.java:115)
	at org.junit.Assert.assertEquals(Assert.java:144)
	at org.elasticsearch.xpack.monitoring.exporter.BaseMonitoringDocTestCase.testToUTC(BaseMonitoringDocTestCase.java:173)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
@cbuescher cbuescher added >test-failure Triaged test failures from CI :Data Management/Monitoring labels Feb 4, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@original-brownbear
Copy link
Member

Another one:

REPRODUCE WITH: ./gradlew :x-pack:plugin:monitoring:unitTest \
  -Dtests.seed=B80D9741EB4E54A0 \
  -Dtests.class=org.elasticsearch.xpack.monitoring.collector.ml.JobStatsMonitoringDocTests \
  -Dtests.method="testToUTC" \
  -Dtests.security.manager=true \
  -Dtests.locale=he-IL \
  -Dtests.timezone=America/Shiprock \
  -Dcompiler.java=11 \
  -Druntime.java=8

https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+intake/1828/console

@jkakavas
Copy link
Member

jkakavas commented Feb 5, 2019

I got one more in a PR run - still doesn't reproduce locally

REPRODUCE WITH: ./gradlew :x-pack:plugin:monitoring:unitTest -Dtests.seed=B110FE213E2190D6 -Dtests.class=org.elasticsearch.xpack.monitoring.collector.indices.IndexRecoveryMonitoringDocTests -Dtests.method="testToUTC" -Dtests.security.manager=true -Dtests.locale=sr-CS -Dtests.timezone=Africa/Lubumbashi -Dcompiler.java=11 -Druntime.java=8

@pgomulka
Copy link
Contributor

pgomulka commented Feb 8, 2019

to be fair, this test does not adds more coverage.
The whole body could be replaced with just a call dateTimeFormatter.formatMillis(timestamp);
i will cover that scenario from failure in DateFormattersTests

pgomulka added a commit that referenced this issue Feb 11, 2019
The test was relying on toString in ZonedDateTime which is different to
what is formatted by strict_date_time when milliseconds are 0
The method is just delegating to dateFormatter, so that scenario should
be covered there.

closes #38359
pgomulka added a commit to pgomulka/elasticsearch that referenced this issue Feb 11, 2019
The test was relying on toString in ZonedDateTime which is different to
what is formatted by strict_date_time when milliseconds are 0
The method is just delegating to dateFormatter, so that scenario should
be covered there.

closes elastic#38359
pgomulka added a commit to pgomulka/elasticsearch that referenced this issue Feb 11, 2019
The test was relying on toString in ZonedDateTime which is different to
what is formatted by strict_date_time when milliseconds are 0
The method is just delegating to dateFormatter, so that scenario should
be covered there.

closes elastic#38359
pgomulka added a commit that referenced this issue Feb 11, 2019
The test was relying on toString in ZonedDateTime which is different to
what is formatted by strict_date_time when milliseconds are 0
The method is just delegating to dateFormatter, so that scenario should
be covered there.

closes #38359
Backport #38610
pgomulka added a commit that referenced this issue Feb 11, 2019
The test was relying on toString in ZonedDateTime which is different to
what is formatted by strict_date_time when milliseconds are 0
The method is just delegating to dateFormatter, so that scenario should
be covered there.

closes #38359
Backport #38610
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants