Bazel écrasant les journaux de test et BuildEventProtocol via BuildEventService

Question

Je suis en train de jouer avec l'implémentation d'un serveur de BuildEventService pour que bazel puisse y exporter ses messages BuildEventProtocol. J'essaie de comprendre comment lire les logs pour un test sans conditions de concurrence, et en particulier cela semble très difficile en raison de bazel réutilisant le même chemin sur la machine locale pour plusieurs exécutions et la nature asynchrone par défaut de BES.

Exemple: Dans le cadre du flux d'événements, je reçois le texte suivant:

EventStream event: 
stream_id { 
    build_id: "a4a34ca2-fc4b-483d-b4ab-b4546bdb2c4e" 
    component: TOOL 
    invocation_id: "b09c0b08-b096-4673-9521-4980506207f7" 
} 
sequence_number: 11 
event { 
    event_time { 
    seconds: 1504560960 
    nanos: 778000000 
    } 
    bazel_event { 
    [type.googleapis.com/build_event_stream.BuildEvent] { 
     id { 
     test_summary { 
      label: "//libraries:types-test" 
      configuration { 
      id: "fe35dfece8e09ba054305e51187b3316" 
      } 
     } 
     } 
     test_summary { 
     total_run_count: 1 
     failed { 
      uri: "file:///private/var/tmp/_bazel_endobson/f851d7f6c7010ae7d7a3db153bed36de/execroot/yaspl/bazel-out/darwin_x86_64-fastbuild/testlogs/libraries/types-test/test.log" 
     } 
     overall_status: FAILED 
     } 
    } 
    } 
} 

Je voudrais lire le fichier dans le uri: file:///private/var/tmp/_bazel_endobson/f851d7f6c7010ae7d7a3db153bed36de/execroot/yaspl/bazel-out/darwin_x86_64-fastbuild/testlogs/libraries/types-test/test.log

mais il semble que chaque fois que je lance le test, je reçois le même uri. Ainsi je veux le lire avant que le prochain essai le recrée. Mais bazel par défaut fait le téléchargement asynchrone, donc il semble qu'il n'y ait rien qui empêche une autre exécution de bazel de démarrer et recréer le fichier avant même que le serveur BES reçoive ce message de flux. Comment puis-je éviter cette course et toujours lire ces fichiers?

Answer 1

Cela dépend si vous contrôlez le client Bazel. Si oui alors vous pouvez éviter la course. Sinon tu ne peux pas.

1. Vous pouvez spécifier un --output_base différent sur chaque invocation de Bazel (La base de sortie est le préfixe de chemin /private/var/tmp/_bazel_endobson/f851d7f6c7010ae7d7a3db153bed36de dans votre exemple). Cependant, --output_base est une option de démarrage et nécessite donc un redémarrage du serveur Bazel lorsqu'il a été modifié. Cela fonctionnerait mais il est lent et vous devez spécifier les différents --output_base avant l'appel, ce qui pourrait être bien si vous appelez Bazel par programmation.
2. Vous pouvez spécifier --bes_best_effort=false auquel cas le téléchargement BES est synchrone, c'est-à-dire que Bazel attend la fin du téléchargement. Si le téléchargement échoue, la génération échoue également.
3. Vous pouvez enrouler le client bazel dans un script shell et également télécharger vers votre service BES, écrire également le BEP dans un fichier, puis à la fin de l'invocation analyser le fichier pour les fichiers test.log et les télécharger avant de donner contrôle de retour à l'utilisateur.