Ce serait super sympa de vérifier avec gradle avant de commencer les tests (ou à chaque exécution quelle que soit la tâche) que nous avons suffisamment d'espace disque dur (plus de 10%).
Sinon, certains tests peuvent échouer.
Par exemple, j'exécutais gradle check
pour un PR non lié à netty3 et il échouait toujours dans le module netty3 avec :
2> REPRODUCE WITH: gradle :modules:transport-netty3:integTest -Dtests.seed=E0B565B5C6B00017 -Dtests.class=org.elasticsearch.http.netty3.Netty3ClientYamlTestSuiteIT -Dtests.method="test {yaml=indices.get_alias/10_basic/Get aliases via /{index}/_alias/name,name}" -Dtests.security.manager=true -Dtests.locale=ar-KW -Dtests.timezone=CET
ERROR 30.1s | Netty3ClientYamlTestSuiteIT.test {yaml=indices.get_alias/10_basic/Get aliases via /{index}/_alias/name,name} <<< FAILURES!
> Throwable #1: java.lang.RuntimeException: Failure at [indices.get_alias/10_basic:5]: listener timeout after waiting for [30000] ms
> at __randomizedtesting.SeedInfo.seed([E0B565B5C6B00017:68E15A6F684C6DEF]:0)
> at org.elasticsearch.test.rest.yaml.ESClientYamlSuiteTestCase.executeSection(ESClientYamlSuiteTestCase.java:327)
> at org.elasticsearch.test.rest.yaml.ESClientYamlSuiteTestCase.test(ESClientYamlSuiteTestCase.java:300)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: listener timeout after waiting for [30000] ms
> at org.elasticsearch.client.RestClient$SyncResponseListener.get(RestClient.java:615)
> at org.elasticsearch.client.RestClient.performRequest(RestClient.java:212)
> at org.elasticsearch.client.RestClient.performRequest(RestClient.java:185)
> at org.elasticsearch.test.rest.yaml.ClientYamlTestClient.callApi(ClientYamlTestClient.java:227)
> at org.elasticsearch.test.rest.yaml.ClientYamlTestExecutionContext.callApiInternal(ClientYamlTestExecutionContext.java:107)
> at org.elasticsearch.test.rest.yaml.ClientYamlTestExecutionContext.callApi(ClientYamlTestExecutionContext.java:72)
> at org.elasticsearch.test.rest.yaml.section.DoSection.execute(DoSection.java:128)
> at org.elasticsearch.test.rest.yaml.ESClientYamlSuiteTestCase.executeSection(ESClientYamlSuiteTestCase.java:325)
> ... 38 more
Quand j'ai regardé modules/transport-netty3/build/cluster/integTest\ node0/elasticsearch-6.0.0-alpha1-SNAPSHOT/logs/modules_transport-netty3_integTest.log
, j'ai vu :
[2016-09-19T10:32:20,078][WARN ][o.e.c.r.a.DiskThresholdMonitor] [tofpR8o] high disk watermark [90%] exceeded on [tofpR8o_Tv-QZ9t2AWtjug][tofpR8o][/Users/dpilato/Documents/Elasticsearch/dev/es-gradle/elasticsearch/modules/transport-netty3/build/cluster/integTest node0/elasticsearch-6.0.0-alpha1-SNAPSHOT/data/nodes/0] free: 2.9gb[0.6%], shards will be relocated away from this node
J'ai cependant 3 Go d'espace disque disponible.
Donc si nous pouvons échouer ou avertir au début de nos tests d'intégration, cela permettrait d'identifier plus rapidement la source du "problème".
Je ne pense pas que nous devrions ajouter des choses comme ça à la construction. La vérification ne serait pas fiable car elle est sujette à des problèmes d'heure de vérification et d'heure d'utilisation, et 90 % n'est probablement même pas la bonne limite à partir d'une version propre (parce que les artefacts, les journaux et un tas d'autres choses sera créé en poussant l'utilisation du disque à plus de 90 % avant que les tests dépendants ne soient exécutés ici).
La bonne chose à faire lorsqu'un test d'intégration échoue est de lire les journaux et cela montrera le problème, comme vous l'avez fait ici.
Je ferme ceci, mais n'hésitez pas à rouvrir @dadoonet si vous pensez le contraire.
Je suis d'accord avec cette réponse. Je disais juste que "c'est bien d'avoir". Je peux totalement vivre sans ça.
Commentaire le plus utile
Je ne pense pas que nous devrions ajouter des choses comme ça à la construction. La vérification ne serait pas fiable car elle est sujette à des problèmes d'heure de vérification et d'heure d'utilisation, et 90 % n'est probablement même pas la bonne limite à partir d'une version propre (parce que les artefacts, les journaux et un tas d'autres choses sera créé en poussant l'utilisation du disque à plus de 90 % avant que les tests dépendants ne soient exécutés ici).
La bonne chose à faire lorsqu'un test d'intégration échoue est de lire les journaux et cela montrera le problème, comme vous l'avez fait ici.