2017-01-11 6 views
2

Мы только что обновили до TFS 2017, и я собираюсь настроить SonarQube integration into pull requests на наши сборки. В процессе я столкнулся с проблемой, которую я не могу понять.SonarQube - не удалось написать сообщение об ошибке

У нас есть три сервера сборки, каждый из которых имеет два набора агентов сборки. Назовем их BA1 и BA2. Кроме того, мы используем новый плагин SonarQube для TFS, а не устаревший, на который ссылается here.

BA2 прекрасно работает. У вас не было ни одной проблемы с созданием отчетов по инкрементному и полному анализу. Тем не менее, любая сборка, которая использует BA1 в конечном счете делает это примерно на полпути через стадию End анализа до отказа с сообщением похожего на это:

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) 

Я уверен, что это не проблема разрешения, потому что все билды работать под та же учетная запись пользователя. Неважно, какой проект или сервер сборки он работает. Все задания, выполняемые с BA2, успешны. Все задания, выполняемые с BA1, с этой ошибкой терпят неудачу. Я видел аналогичный вопрос here, но решение этой проблемы не сработает для меня. У меня нет проблемы с очередным заданием, стоящим в очереди в одном рабочем пространстве.

Просто пытаясь понять, возможно ли это, когда-либо сталкивался с этим раньше. Я проверил журналы агента сборки в каталоге _diag, но не смог найти ничего полезного. У меня кончились идеи проверить. Спасибо за любые советы.

+0

Не могли бы вы поделиться файлом .agent с BA1 и BA2? В частности, убедитесь, что они не используют один и тот же _workingDirectory_ (т. Е. E: \ workingDirectory). –

+0

Являются ли BA1 и BA2 с точки зрения конфигурации одинаковыми, и вы нашли некоторые pb-файлы в каталоге? –

+0

Не могли бы вы воспроизвести эту проблему, если вы настроите другой агент сборки? –

ответ

1

Оказалось, что для сборок, которые были повреждены приводом (E :) был отформатирован как привод FAT32 RAM. Привод не был полным, но мы по-прежнему сталкивались с каким-то ограничением на этом диске, который вызывал сбои сборки.

Я не думаю, что это ограничение количества файлов, потому что мы удалили несколько файлов из каталога и попытались добавить новый, и это не позволит нам добавить его. Когда я удалил все файлы в каталоге batch-report, он, наконец, разрешил мне добавлять файлы снова. Я предполагаю, что это был какой-то лимит размера каталога, который вызывал проблему. В любом случае, вместо того, чтобы тратить время на то, чтобы выяснить, в чем причина, мы переформатировали диск в NTFS, и проблемы с сборкой ушли. Спасибо всем за идеи и советы.