2017-01-11 5 views
2

Wir haben gerade auf TFS 2017 aktualisiert und ich bin dabei, SonarQube integration into pull requests für unsere Builds einzurichten. In diesem Prozess bin ich auf ein Problem gestoßen, das ich nicht zu verstehen scheint.SonarQube - Nachricht konnte nicht geschrieben werden

Wir haben drei Build-Server mit jeweils zwei Build-Agents auf ihnen. Nennen wir sie BA1 und BA2. Außerdem verwenden wir das neue SonarQube-Plugin für TFS, nicht das veraltete, das auf here verweist.

BA2 funktioniert perfekt. Es gab kein einziges Problem beim Erstellen von inkrementellen und vollständigen Analyseberichten. Jedoch kann jeder bauen, dass BA1 letztlich macht es etwa auf halbem Weg durch den End-Analyse Schritt vor dem Versagen mit einer Meldung ähnlich wie diese verwendet:

ERROR: Error during SonarQube Scanner execution 
org.sonar.core.util.ContextException: Unable to write message | file=E:\workingDirectory\_work\3\.sonarqube\out\.sonar\batch-report\component-5072.pb 

... //long stacktrace 

Caused by: java.io.FileNotFoundException: E:\workingDirectory\_work\3\.sonarqube\out\.sonar\batch-report\component-5072.pb (The directory or file cannot be created) 

Ich bin mir ziemlich sicher, dass es kein Berechtigungsproblem, weil alle unter den Builds gleiches Benutzerkonto. Es spielt keine Rolle, auf welchem ​​Projekt oder Build-Server es läuft. Alle Jobs, die mit BA2 ausgeführt werden, sind erfolgreich. Alle Jobs, die mit BA1 ausgeführt werden, schlagen mit diesem Fehler fehl. Ich sah eine ähnliche Frage here, aber die Lösung für dieses Problem wird nicht für mich arbeiten. Ich habe kein Problem damit, dass ein anderer Job in den gleichen Arbeitsbereich eingereiht wird.

Nur versuchen zu sehen, ob es irgendjemandem schon einmal begegnet ist. Ich habe die Build-Agent-Protokolle im Verzeichnis _diag überprüft, konnte aber nichts Nützliches finden. Ich habe keine Ideen mehr, um das zu überprüfen. Danke für irgendwelche Tipps.

+0

Könnten Sie bitte die .agent-Datei von BA1 und BA2 teilen? Stellen Sie insbesondere sicher, dass sie nicht das gleiche _workingDirectory_ verwenden (d. H. E: \ workingDirectory) –

+0

Sind BA1 und BA2 in Bezug auf die Konfiguration gleich und haben Sie einige PB-Dateien im Verzeichnis gefunden? –

+0

Können Sie dieses Problem reproduzieren, wenn Sie einen anderen Build-Agenten konfigurieren? –

Antwort

1

Stellt sich heraus, dass für die Builds, die fehlgeschlagen sind, das Laufwerk (E :) wurde als ein FAT32-RAM-Laufwerk formatiert. Das Laufwerk war nicht voll, aber wir trafen immer noch ein Limit auf dem Laufwerk, das die Builds fehlschlagen ließ.

Ich glaube nicht, dass es eine Begrenzung der Dateianzahl war, weil wir mehrere Dateien aus dem Verzeichnis gelöscht haben und versucht haben, eine neue hinzuzufügen, und es würde uns nicht erlauben, eine hinzuzufügen. Als ich alle Dateien unter dem batch-report Verzeichnis löschte, erlaubte es mir schließlich, Dateien wieder hinzuzufügen. Ich gehe davon aus, dass es eine Art Verzeichnisgröße gab, die das Problem verursacht hat. Auf jeden Fall, anstatt Zeit zu verschwenden, um herauszufinden, was genau die Ursache war, formatierten wir die Festplatte auf NTFS und die Build-Probleme verschwanden. Danke an alle für die Ideen und Tipps.

Verwandte Themen