Какой XSLT вы используете для форматирования вывода MsBuild XML в CruiseControl.Net?

Question

В настоящее время мы не форматируем наш вывод msbuild в CC.NET (CruiseControl.Net) и, как следствие, поиск причины сбоя сборки включает чтение XML, чтобы найти последний экземпляр success = "false" выход.

Какой XSLT вы используете для форматирования вывода msbuild, и довольны ли вы полученным HTML? То есть Вам легко определить причину сломанной сборки?

Спасибо б

EDIT: Вот обработанный образец одного из наших элементов XML проекта CC. Теперь мне интересно, является ли слияние логов проблемой.

    <project name="StackOverflowSample">
    <workingDirectory>D:\_300</workingDirectory>
    <webURL>&viewFarmReportWebURL;</webURL>
    <sourcecontrol type="multi">
        <sourceControls>
            <vsts>
                <!-- We get latest from TSF -->
            </vsts>
        </sourceControls>
    </sourcecontrol>
    <triggers>
        <intervalTrigger seconds="60" />
    </triggers>
    <tasks>
        <msbuild>
            <executable>&msbuildExecutable;</executable>
            <workingDirectory>app\consoleApp1</workingDirectory>
            <projectFile>consoleApp1.sln</projectFile>
            <buildArgs>/noconlog /p:Configuration=Release /v:quiet</buildArgs>
            <logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,"D:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll"</logger>
        </msbuild>
        <nunit>
            <path>&nunitConsoleExecutable;</path>
            <assemblies>
                <assembly> D:\_300\app\consoleApp1\bin\Release\consoleApp1.exe</assembly>
            </assemblies>
        </nunit>
        <exec>
            <executable>&ncoverExecutable;</executable>
            <buildArgs>"&nunitConsoleExecutable;" "app\consoleApp1\bin\Release\consoleApp1.exe" /nologo</buildArgs>
        </exec>
        <exec>
            <executable>&ndependExecutable;</executable>
            <buildArgs>D:\_300\app\consoleApp1.xml /Silent</buildArgs>
        </exec>

        <merge>
            <files>
                <file>D:\_300\app\consoleApp1\unit-test.xml</file>
                <file>D:\_300\app\consoleApp1\ApplicationMetrics.xml</file>
                <file>D:\_300\app\consoleApp1\AssembliesBuildOrder.xml</file>
                <file>D:\_300\app\consoleApp1\AssembliesDependencies.xml</file>
                <file>D:\_300\app\consoleApp1\AssembliesMetrics.xml</file>
                <file>D:\_300\app\consoleApp1\CQLResult.xml</file>
                <file>D:\_300\app\consoleApp1\InfoWarnings.xml</file>
                <file>D:\_300\app\consoleApp1\NDependMain.xml</file>
                <file>D:\_300\app\consoleApp1\TypesDependencies.xml</file>
                <file>D:\_300\app\consoleApp1\TypesMetrics.xml</file>
            </files>
        </merge>
    </tasks>
    <publishers>
        <merge>
            <files>
                <file>D:\_300\app\consoleApp1\SymbolModule.Xml</file>
            </files>
        </merge>
        <xmllogger logDir="." />
        &emailconsoleApp1;
    </publishers>
</project>

Answer 1

Я пробовал CruiseControl.Net 1.4.4.83 с Rodemeyer.MsBuildToCCnet.dll 1.0.0.5 в качестве регистратора в сочетании с msbuild2ccnet.xsl и выходные данные не похожи на выходные образцы из статьи:

Build started
Project "" (Integration.Common.csproj target(s)):
error CS1002: 
Build succeeded
error CS1002: 
1 Error(s)
0 Warning(s)
Time elapsed

Использование ThoughtWorks.CruiseControl.MSBuild.dll в качестве регистратора в сочетании с msbuild.xsl , результаты просто отличные:

Build started 07/16/2009 13:46:38
Person.cs (18,53):  error CS1002: ; expected
Build FAILED
Person.cs (18,53):  error CS1002: ; expected
1 Error(s)
0 Warning(s)
Time elapsed 00:00:00

Answer 2

После разговора с разработчиками (мне сказали, что альтернативный логгер, на который вы ссылаетесь, довольно старый, и его использование не рекомендуется), я использую стандартный логгер по умолчанию и xslt. Если это вызывает у вас проблемы, пожалуйста, сообщите об ошибке на CruiseControl.Net Jira , чем больше людей проголосует за это, тем скорее кто-то с коммитом доступа к коду может его изучить.

«Просмотр журнала сборки» - это необработанное представление, которое нельзя использовать, за исключением отладки настроек сервера сборки - для некоторых моих проектов оно имеет размер почти 5 МБ и не вызывает никаких проблем для сервера (хотя при его открытии браузер зависает для какое-то время). NCover может вызвать проблемы, увеличивая buildlog.xml до более чем 100 МБ - вы должны использовать NCoverExplorer для анализа результатов перед их объединением, если это произойдет (но не беспокойтесь, прежде чем вы начнете получать исключения с сервера).

Чтобы просмотреть отформатированные результаты MSBuild в WebDashboard, убедитесь, что в конфигурацию панели инструментов входит msbuild.xsl (это даст вам ссылку на «MSBuild Report» на странице ViewBuildReport и включит некоторую основную информацию о сама страница).

Answer 3

Мне немного странно отвечать на мой собственный вопрос, но есть шанс, что у кого-то возникнет тот же вопрос и он оценит мой ответ, поэтому вот он.

Я посетил следующую страницу http://confluence.public.thoughtworks.org/display/CCNETCOMM/Improved+MSBuild+Integration, которая описывает использование регистратора, отличного от традиционного регистратора (обычный регистратор создает очень большие файлы, которые приводят сервер в тупик при выполнении преобразований XSLT).

На странице представлен регистратор и файл XSLT, а также простые и понятные инструкции о том, как включить это в ваш проект CC.Net. Я попробовал этот регистратор и XSLT и обнаружил, что все еще получаю необработанный XML; на самом деле, ВСЕ XML в одной огромной странице.