PublishTestResults@2 – Aufgabe "Testergebnisse veröffentlichen v2" veröffentlichen

Veröffentlichen sie Testergebnisse in Azure Pipelines.

Syntax

# Publish Test Results v2
# Publish test results to Azure Pipelines.
- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit' # 'JUnit' | 'NUnit' | 'VSTest' | 'XUnit' | 'CTest'. Alias: testRunner. Required. Test result format. Default: JUnit.
    testResultsFiles: '**/TEST-*.xml' # string. Required. Test results files. Default: **/TEST-*.xml.
    #searchFolder: '$(System.DefaultWorkingDirectory)' # string. Search folder. Default: $(System.DefaultWorkingDirectory).
    #mergeTestResults: false # boolean. Merge test results. Default: false.
    #failTaskOnFailedTests: false # boolean. Fail if there are test failures. Default: false.
    #failTaskOnFailureToPublishResults: false # boolean. Fail if there is failure in publishing test results. Default: false.
    #failTaskOnMissingResultsFile: false # boolean. Fail if no result files are found. Default: false.
    #testRunTitle: # string. Test run title. 
  # Advanced
    #buildPlatform: # string. Alias: platform. Build Platform. 
    #buildConfiguration: # string. Alias: configuration. Build Configuration. 
    #publishRunAttachments: true # boolean. Upload test results files. Default: true.

Eingaben

testResultsFormat - Testergebnisformat
Eingabealias: testRunner. string. Erforderlich. Zulässige Werte: JUnit, NUnit, VSTest, XUnit, CTest. Standardwert. JUnit.

Gibt das Format der Ergebnisdateien an, die Sie veröffentlichen möchten. Die folgenden Formate werden unterstützt: CTest, JUnit, NUnit 2, NUnit 3, Visual Studio Test (TRX) und xUnit 2.

testResultsFiles - Testergebnisdateien
string. Erforderlich. Standardwert. **/TEST-*.xml.

Gibt mindestens eine Testergebnisdatei an.

• Sie können einen Platzhalter für einzelne Ordner (*) und rekursive Platzhalter (**) verwenden. **/TEST-*.xml sucht beispielsweise nach allen XML-Dateien, deren Namen in allen Unterverzeichnissen mit TEST- beginnen. Wenn Sie VSTest als Testergebnisformat verwenden, sollte der Dateityp in .trx geändert werden, z. B. **/TEST-*.trx.
• Es können mehrere Pfade angegeben werden, die durch eine neue Zeile getrennt werden.
• Akzeptiert außerdem Minimatchmuster.

!TEST[1-3].xml schließt z. B. Dateien mit dem Namen TEST1.xml, TEST2.xml oder TEST3.xml aus.

searchFolder - ordner Search
string. Standardwert. $(System.DefaultWorkingDirectory).

Optional. Gibt den Ordner an, in dem nach den Testergebnisdateien gesucht werden soll.

mergeTestResults - Zusammenführen von Testergebnissen
boolean. Standardwert. false.

Wenn der Wert dieses booleschen Werts ist, meldet trueder Task Testergebnisse aus allen Dateien für eine einzelne Testausführung. Wenn der Wert ist false, erstellt der Task einen separaten Testlauf für jede Testergebnisdatei.

Hinweis

Verwenden Sie die Einstellung Mergetestergebnisse, um Dateien aus demselben Testframework zu kombinieren, um sicherzustellen, dass die Ergebniszuordnung und -dauer ordnungsgemäß berechnet werden.

failTaskOnFailedTests - Fehler bei Testfehlern
boolean. Standardwert. false.

Optional. Wenn der Wert dieses booleschen Werts ist true, schlägt die Aufgabe fehl, wenn einer der Tests in der Ergebnisdatei als fehlgeschlagen markiert ist. Der Standardwert ist false, wodurch einfach die Ergebnisse aus der Ergebnisdatei veröffentlicht werden.

failTaskOnFailureToPublishResults - Fehler bei der Veröffentlichung von Testergebnissen
boolean. Standardwert. false.

Wenn true, schlägt die Aufgabe fehl, wenn bei der Veröffentlichung von Testergebnissen ein Fehler auftritt.

failTaskOnMissingResultsFile - Fehler, wenn keine Ergebnisdateien gefunden werden
boolean. Standardwert. false.

Führen Sie einen Fehler beim Task durch, wenn keine Ergebnisdateien gefunden werden.

testRunTitle - Titel der Testausführung
string.

Optional. Gibt einen Namen für die Testausführung an, für die die Ergebnisse gemeldet werden. In der Build- oder Releasepipeline deklarierte Variablennamen können verwendet werden.

buildPlatform - Plattform erstellen
Eingabealias: platform. string.

Optional. Gibt die Buildplattform an, auf der die Testausführung gemeldet werden soll. Zum Beispiel: x64 oder x86. Wenn Sie eine Variable für die Plattform in Ihrem Buildtask definiert haben, verwenden Sie sie hier.

buildConfiguration - Buildkonfiguration
Eingabealias: configuration. string.

Optional. Gibt die Buildkonfiguration an, für die die Testausführung gemeldet werden soll. Zum Beispiel: Debug oder Release. Wenn Sie eine Variable für die Konfiguration in Ihrem Buildtask definiert haben, verwenden Sie sie hier.

publishRunAttachments - Hochladen von Testergebnisdateien
boolean. Standardwert. true.

Optional. Wenn der Wert dieses booleschen Werts ist true, lädt die Aufgabe alle Testergebnisdateien als Anlagen in die Testausführung hoch.

Optionen für die Vorgangskontrolle

Alle Vorgänge verfügen zusätzlich zu ihren Eingaben über Steuerungsoptionen. Weitere Informationen finden Sie unter Steuerungsoptionen und allgemeine Aufgabeneigenschaften.

Ausgabevariablen

Keine.

Hinweise

• Voraussetzungen
• Aufgabenstandardeinstellungen
• Zuordnung von Ergebnisformaten
• Anlagenunterstützung

Diese Aufgabe veröffentlicht Testergebnisse in Azure Pipelines oder TFS, wenn Tests ausgeführt werden, um eine umfassende Testberichterstellungs- und Analyseumgebung bereitzustellen. Sie können den Testrunner Ihrer Wahl verwenden, der das gewünschte Ergebnisformat unterstützt. Zu den unterstützten Ergebnisformaten gehören CTest, JUnit (einschließlich PHPUnit), NUnit 2, NUnit 3, Visual Studio Test (TRX) und xUnit 2.

Andere integrierte Aufgaben, z. B . Visual Studio Test-Task und Dot NetCore CLI-Task , veröffentlichen Automatisch Testergebnisse in der Pipeline. Aufgaben wie Ant, Maven, Gulp, Grunt und Xcode bieten Veröffentlichungsergebnisse als Option innerhalb der Aufgabe oder erstellen Bibliotheken wie Cobertura und JaCoCo. Wenn Sie eine dieser Aufgaben verwenden, benötigen Sie keine separate Aufgabe zum Veröffentlichen von Testergebnissen in der Pipeline.

Die veröffentlichten Testergebnisse werden auf der Registerkarte Tests in der Pipelinezusammenfassung angezeigt. Die Ergebnisse helfen Ihnen dabei, die Qualität der Pipeline zu messen, die Rückverfolgbarkeit zu überprüfen, Fehler zu beheben und den Besitz von Laufwerksfehlern zu überprüfen.

Das folgende Beispiel zeigt, dass die Aufgabe für die Veröffentlichung von Testergebnissen konfiguriert ist.

Sie können diese Aufgabe auch in einer Buildpipeline verwenden, um Code Coverage-Ergebnisse zu veröffentlichen, die beim Ausführen von Tests in Azure Pipelines oder TFS erstellt wurden, um Berichte zur Abdeckung zu erhalten.

Voraussetzungen

Wenn Sie einen selbstgehosteten Windows-Agent verwenden, muss auf Ihrem Computer die folgende Voraussetzung installiert sein:

• .NET Framework 4.6.2 oder höher

Aufgabenstandardeinstellungen

Die Standardoption verwendet das JUnit-Format, um Testergebnisse zu veröffentlichen. Wenn Sie VSTest als testRunner verwenden, sollte die Option testResultsFiles in **/TEST-*.trx geändert werden.

testResultsFormat ist ein Alias für den testRunner-Eingabenamen. Die Ergebnisdateien können von mehreren Runnern und nicht nur von einem bestimmten Runner erstellt werden. Beispielsweise wird das jUnit-Ergebnisformat von vielen Runnern und nicht nur von jUnit unterstützt.

Informationen zum Veröffentlichen von Testergebnissen für Python mithilfe von YAML finden Sie unter Python im Abschnitt Ökosysteme dieser Themen, der auch Beispiele für andere Sprachen enthält.

Zuordnung von Ergebnisformaten

In dieser Tabelle werden die Felder aufgelistet, die auf der Registerkarte „Tests“ in einer Build- oder Releasezusammenfassung gemeldet werden, und die entsprechende Zuordnung mit den Attributen in den unterstützten Testergebnisformaten.

Visual Studio Test (TRX)

`Scope`	Feld	Visual Studio Test (TRX)
Testlauf	Titel	In der Aufgabe angegebener Testlauftitel
	Startdatum	/TestRun/Times.Attributes["start"].Value
	Abschlussdatum	/TestRun/Times.Attributes["finish"].Value
	Duration	Abschlussdatum – Startdatum
	Attachments	Weitere Informationen finden Sie weiter unten im Abschnitt Anlagenunterstützung.
Testergebnis	Titel	/TestRun/Results/UnitTestResult.Attributes["testName"].Value Oder /TestRun/Results/WebTestResult.Attributes["testName"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["testName"].Value
	Startdatum	/TestRun/Results/UnitTestResult.Attributes["startTime"].Value Oder /TestRun/Results/WebTestResult.Attributes["startTime"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["startTime"].Value
	Abschlussdatum	/TestRun/Results/UnitTestResult.Attributes["startTime"].Value + /TestRun/Results/UnitTestResult.Attributes["duration"].Value Oder /TestRun/Results/WebTestResult.Attributes["startTime"].Value + /TestRun/Results/WebTestResult.Attributes["duration"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["startTime"].Value + /TestRun/Results/TestResultAggregation.Attributes["duration"].Value
	Duration	/TestRun/Results/UnitTestResult.Attributes["duration"].Value Oder /TestRun/Results/WebTestResult.Attributes["duration"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["duration"].Value
	Besitzer	/TestRun/TestDefinitions/UnitTest/Owners/Owner.Attributes["name"].Value
	Ergebnis	/TestRun/Results/UnitTestResult.Attributes["outcome"].Value Oder /TestRun/Results/WebTestResult.Attributes["outcome"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["outcome"].Value
	Fehlermeldung	/TestRun/Results/UnitTestResult/Output/ErrorInfo/Message.InnerText Oder /TestRun/Results/WebTestResultOutput/ErrorInfo/Message.InnerText Oder /TestRun/Results/TestResultAggregation/Output/ErrorInfo/Message.InnerText
	Stapelüberwachung	/TestRun/Results/UnitTestResult/Output/ErrorInfo/StackTrace.InnerText Oder /TestRun/Results/WebTestResultOutput/ErrorInfo/StackTrace.InnerText Oder /TestRun/Results/TestResultAggregation/Output/ErrorInfo/StackTrace.InnerText
	Attachments	Weitere Informationen finden Sie weiter unten im Abschnitt Anlagenunterstützung.
	Konsolenprotokoll	/TestRun/Results/UnitTestResult/Output/StdOut.InnerText Oder /TestRun/Results/WebTestResultOutput/Output/StdOut.InnerText Oder /TestRun/Results/TestResultAggregation/Output/StdOut.InnerText
	Konsolenfehlerprotokoll	/TestRun/Results/UnitTestResult/Output/StdErr.InnerText Oder /TestRun/Results/WebTestResultOutput/Output/StdErr.InnerText Oder /TestRun/Results/TestResultAggregation/Output/StdErr.InnerText
	Agent-Name	/TestRun/Results/UnitTestResult.Attributes["computerName"].Value Oder /TestRun/Results/WebTestResult.Attributes["computerName"].Value Oder /TestRun/Results/TestResultAggregation.Attributes["computerName"].Value
	Testdatei	/TestRun/TestDefinitions/UnitTest.Attributes["storage"].Value
	Priority	/TestRun/TestDefinitions/UnitTest.Attributes["priority"].Value

JUnit

`Scope`	Feld	JUnit
Testlauf	Titel	In der Aufgabe angegebener Testlauftitel
	Startdatum	/testsuites/testsuite.Attributes["timestamp"].Value
	Abschlussdatum	/testsuites/testsuite.Attributes["timestamp"].Value + SUM(/testsuites/testsuite/testcase.Attributes["time"].Value) für alle Testfälle in der Testsammlung
	Duration	Abschlussdatum – Startdatum
	Attachments	Ergebnisdatei, die zum Veröffentlichen von Testergebnissen verwendet wird
Testergebnis	Titel	/testsuites/testsuite/testcase/Attributes["name"].Value
	Startdatum	/testsuites/testsuite.Attributes["timestamp"].Value
	Abschlussdatum	/testsuites/testsuite.Attributes["timestamp"].Value + /testsuites/testsuite/testcase.Attributes["time"].Value
	Duration	/testsuites/testsuite/testcase/.Attributes["time"].Value
	Besitzer	/testsuites/testsuite/testcase/Attributes["owner"].Value
	Ergebnis	Fehler: wenn „/Testsuites/testsuite/testcase/failure“ Oder „/Testsuites/testsuite/testcase/error“ vorliegt Nicht ausgeführt: wenn „Testsuites/testsuite/testcase/skipped“ vorliegt Bestanden: alle anderen Fälle
	Fehlermeldung	/Testsuites/testsuite/testcase/failure.Attributes["message"].Value Oder /Testsuites/testsuite/testcase/error.Attributes["message"].Value Oder /Testsuites/testsuite/testcase/skipped.Attributes["message"].Value
	Stapelüberwachung	/Testsuites/testsuite/testcase/failure.InnerText Oder /Testsuites/testsuite/testcase/error.InnerText
	Attachments	-
	Konsolenprotokoll	/Testsuites/testsuite/testcase/system-out
	Konsolenfehlerprotokoll	/Testsuites/testsuite/testcase/system-err
	Agent-Name	/testsuites/testsuite.Attributes["hostname"].Value
	Testdatei	/testsuites/testsuite/testcase/Attributes["classname"].Value
	Priority	-

NUnit 2

`Scope`	Feld	NUnit 2
Testlauf	Titel	In der Aufgabe angegebener Testlauftitel
	Startdatum	/test-results.Attributes["date"].Value + /test-results.Attributes["time"].Value
	Abschlussdatum	Startdatum + /test-results/results/test-case. Attribute["time"].Value für alle Testfälle
	Duration	Abschlussdatum – Startdatum
	Attachments	Ergebnisdatei, die zum Veröffentlichen von Testergebnissen verwendet wird
Testergebnis	Titel	/test-results/results/test-case.Attributes["name"].Value
	Startdatum	/test-results.Attributes["date"].Value + /test-results.Attributes["time"].Value
	Abschlussdatum	Startdatum + /test-results/results/test-case.Attribute["time"].Value
	Duration	/test-results/results/test-case.Attributes["time"].Value
	Besitzer	Build- oder Releaseanforderung für Benutzer*in
	Ergebnis	Fehler: wenn „/test-results/results/test-case/failure“ vorliegt Nicht ausgeführt: wenn „/test-results/test-case. Attribute["result"].Value=="Ignored"“ vorliegt Bestanden: alle anderen Fälle
	Fehlermeldung	/test-results/results/test-casefailure/message.InnerText
	Stapelüberwachung	/test-results/results/test-case/failure/stack-trace.InnerText
	Attachments	-
	Konsolenprotokoll	/test-results/results/test-case/failure/message.InnerText
	Konsolenfehlerprotokoll	/test-results/results/test-case/output.InnerText
	Agent-Name	/test-results/environment.Attributes["machine-name"].Value
	Testdatei	/test-results/test-suite.Attributes["name"].Value
	Priority	-

NUnit 3

`Scope`	Feld	NUnit 3
Testlauf	Titel	In der Aufgabe angegebener Testlauftitel
	Startdatum	/test-run/start-time
	Abschlussdatum	/test-run/end-time
	Duration	Abschlussdatum – Startdatum
	Attachments	Weitere Informationen finden Sie weiter unten im Abschnitt Anlagenunterstützung.
Testergebnis	Titel	/test-suite[@type='Assembly']/test-case.Attributes["name"].Value
	Startdatum	/test-suite[@type='Assembly']/test-case.Attributes["start-time"].Value
	Abschlussdatum	/test-suite[@type='Assembly']/test-case.Attributes["end-time"].Value
	Duration	/test-suite[@type='Assembly']/test-case.Attributes["duration"].Value
	Besitzer	Build- oder Releaseanforderung für Benutzer*in
	Ergebnis	/test-results/test-suite/results/test-case.Attributes["result"].Value
	Fehlermeldung	/test-suite[@type='Assembly']/test-case/failure/message
	Stapelüberwachung	/test-suite[@type='Assembly']//test-case/failure/stack-trace
	Attachments	Weitere Informationen finden Sie weiter unten im Abschnitt Anlagenunterstützung.
	Konsolenprotokoll	/test-suite[@type='Assembly']/test-case/failure/output
	Konsolenfehlerprotokoll	-
	Agent-Name	/test-suite[@type='Assembly']/environment.Attributes["machine-name"].Value
	Testdatei	/test-suite[@type='Assembly'].Attributes["name"].Value
	Priority	-

xUnit 2

`Scope`	Feld	xUnit 2
Testlauf	Titel	In der Aufgabe angegebener Testlauftitel
	Startdatum	/assemblies/assembly/run-date + /assemblies/assembly/run-time
	Abschlussdatum	Startdatum + /assemblies/assembly/time
	Duration	Abschlussdatum – Startdatum
	Attachments	Ergebnisdatei, die zum Veröffentlichen von Testergebnissen verwendet wird
Testergebnis	Titel	/assemblies/assembly/collection/test.Attributes["method"].Value
	Startdatum	/assemblies/assembly/run-date + /assemblies/assembly/run-time
	Abschlussdatum	Startdatum + /assemblies/assembly/collection/test.Attributes["time"].Value
	Duration	/assemblies/assembly/collection/test.Attributes["time"].Value
	Besitzer	/assemblies/assembly/collection/test/traits/trait[@name='owner'].Attributes["value"].Value
	Ergebnis	/assemblies/assembly/collection/test/failure.Attributes["result"].Value
	Fehlermeldung	/assemblies/assembly/collection/test/failure/message
	Stapelüberwachung	/assemblies/assembly/collection/test/failure/stack-trace
	Attachments	-
	Konsolenprotokoll	/assemblies/assembly/collection/test/failure/output
	Konsolenfehlerprotokoll	-
	Agent-Name	-
	Testdatei	/assemblies/assembly.Attributes["name"].Value
	Priority	/testcaseNode/traits/trait[@name='priority'].Attributes["value"].Value

CTest

`Scope`	Feld	CTest
Testlauf	Titel	In der Aufgabe angegebener Testlauftitel
	Startdatum	/Site/Testing/StartTestTime.InnerText
	Abschlussdatum	/Site/Testing/EndTestTime.InnerText
	Duration	Abschlussdatum – Startdatum
	Attachments	Ergebnisdatei, die zum Veröffentlichen von Testergebnissen verwendet wird
Testergebnis	Titel	/Site/Testing/Test/Name.InnerText
	Startdatum	/Site/Testing/StartTestTime.InnerText
	Abschlussdatum	Startdatum + /Site/Testing/Test/Results/NamedMeasurement[@name= 'Ausführungszeit']/Value.InnerText
	Duration	/Site/Testing/Test/Results/NamedMeasurement[@name= 'Ausführungszeit']/Value.InnerText
	Besitzer	Build- oder Releaseanforderung für Benutzer*in
	Ergebnis	/Site/Testing/Test.Attributes["Status"].Value
	Fehlermeldung	-
	Stapelüberwachung	/Site/Testing/Test/Results/Measurement/Value.InnerText
	Attachments	-
	Konsolenprotokoll	-
	Konsolenfehlerprotokoll	-
	Agent-Name	-
	Testdatei	/Site/Testing/Test/Path.InnerText
	Priority	-

Hinweis

Dauer wird nur verwendet, wenn Startdatum und Abschlussdatum nicht verfügbar sind.

Das vollqualifizierte Namensformat für testName ist Namespace.Testclass.Methodname mit einem Zeichenlimit von 512. Wenn der Test datengesteuert ist und Parameter aufweist, enthält das Zeichenlimit die Parameter.

Beim Veröffentlichen des Testergebnisses erhalten Sie möglicherweise folgende Fehlermeldung: Fehler beim Veröffentlichen von Testergebnissen: Ungültige Priorität angegeben

Dieser Fehler tritt auf, wenn für eine der Testmethoden die Priorität über 255 festgelegt ist, die Testmethodenpriorität im Code behoben und die Tests erneut ausgeführt werden. Sie können die generierte trx-Datei überprüfen, um zu sehen, dass alle Tests die Priorität größer als 255 haben.

Anlagenunterstützung

Die Aufgabe „Testergebnisse veröffentlichen“ bietet Unterstützung für Anlagen für Testläufe und Testergebnisse für die folgenden Formate. Für öffentliche Projekte unterstützen wir insgesamt 2 GB Anlagen.

Visual Studio Test (TRX)

Visual Studio Test (TRX)

`Scope`	type	Pfad
Testlauf	Datensammler	/TestRun/ResultSummary/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"].Value
	Testergebnis	/TestRun/ResultSummary/ResultFiles/ResultFile.Attributes["path"].Value
	Code Coverage	/TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attributes["binaryFile"].Value Und /TestRun/TestSettings/Execution/AgentRule/DataCollectors/DataCollector/Configuration/CodeCoverage/Regular/CodeCoverageItem.Attributes["pdbFile"].Value
Testergebnis	Datensammler	/TestRun/Results/UnitTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"].Value Oder /TestRun/Results/WebTestResult/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"].Value Oder /TestRun/Results/TestResultAggregation/CollectorDataEntries/Collector/UriAttachments/UriAttachment/A.Attributes["href"].Value
	Testergebnis	/TestRun/Results/UnitTestResult/ResultFiles/ResultFile.Attributes["path"].Value Oder /TestRun/Results/WebTestResult/ResultFiles/ResultFile.Attributes["path"].Value Oder /TestRun/Results/TestResultAggregation/ResultFiles/ResultFile.Attributes["path"].Value

NUnit 3

NUnit 3

`Scope`	Pfad
Testlauf	/test-suite/attachments/attachment/filePath
Testlauf	/test-suite[@type='Assembly']/test-case/attachments/attachment/filePath

JUnit

JUnit

`Scope`	Pfad
Testergebnis	/testsuites/testsuite/testcase/system-out/ –> Inhaltsvergleichsmuster [[ATTACHMENT|filePath]]

Hinweis

Die Option zum Hochladen der Testergebnisdatei als Anlage ist eine Standardoption in der Aufgabe, die für alle Formate gilt.

Beispiele

Docker

Für Docker-basierte Apps gibt es viele Möglichkeiten, Ihre Anwendung zu erstellen und Tests auszuführen:

• Erstellen und Testen in einer Buildpipeline: Builds und Tests werden in der Pipeline ausgeführt, und die Testergebnisse werden mithilfe der Aufgabe Testergebnisse veröffentlichen veröffentlicht.
• Erstellen und Testen mit einer mehrstufigen Dockerfile-Datei: Builds und Tests werden im Container mithilfe einer mehrstufigen Docker-Datei ausgeführt, da solche Testergebnisse nicht in der Pipeline veröffentlicht werden.
• Erstellen, Testen und Veröffentlichen von Ergebnissen mit einer Dockerfile: Builds und Tests werden innerhalb des Containers ausgeführt, und die Ergebnisse werden wieder in der Pipeline veröffentlicht. Betrachten Sie das folgende Beispiel.

Erstellen, Testen und Veröffentlichen von Ergebnissen mit einem Dockerfile

Bei diesem Ansatz erstellen Sie Ihren Code und führen Tests im Container mithilfe eines Dockerfiles aus. Die Testergebnisse werden dann auf den Host kopiert, um in der Pipeline veröffentlicht zu werden. Um die Testergebnisse in Azure Pipelines zu veröffentlichen, können Sie die Aufgabe Testergebnisse veröffentlichen verwenden. Das endgültige Image wird in Docker oder Azure Container Registry veröffentlicht.

Abrufen des Codes

1. Erstellen Sie eine Dockerfile.build-Datei im Stammverzeichnis Ihres Projektverzeichnisses mit folgendem Befehl:

   # Build and run tests inside the docker container
   FROM mcr.microsoft.com/dotnet/sdk:2.1
   WORKDIR /app
   # copy the contents of agent working directory on host to workdir in container
   COPY . ./
   # dotnet commands to build, test, and publish
   RUN dotnet restore
   RUN dotnet build -c Release
   RUN dotnet test dotnetcore-tests/dotnetcore-tests.csproj -c Release --logger "trx;LogFileName=testresults.trx"
   RUN dotnet publish -c Release -o out
   ENTRYPOINT dotnet dotnetcore-sample/out/dotnetcore-sample.dll
   

   Diese Datei enthält die Anweisungen zum Erstellen von Code und zum Ausführen von Tests. Die Tests werden dann in eine Datei testresults.trx im Container kopiert.

2. Um das endgültige Image, das nur die Laufzeit- und Bereitstellungsartefakte enthält, so klein wie möglich zu machen, ersetzen Sie den Inhalt des vorhandenen Dockerfile durch Folgendes:

   # This Dockerfile creates the final image to be published to Docker or
   # Azure Container Registry
   # Create a container with the compiled asp.net core app
   FROM mcr.microsoft.com/dotnet/aspnet:2.1
   # Create app directory
   WORKDIR /app
   # Copy only the deployment artifacts
   COPY /out .
   ENTRYPOINT ["dotnet", "dotnetcore-sample.dll"]
   

Definieren der Buildpipeline

YAML

1. Wenn Sie über ein Docker Hub-Konto verfügen und das Image per Push an Ihre Docker-Registrierung übertragen möchten, ersetzen Sie den Inhalt der Datei .vsts-ci.docker.yml durch Folgendes:

   # Build Docker image for this app, to be published to Docker Registry
   pool:
     vmImage: 'ubuntu-latest'
   variables:
     buildConfiguration: 'Release'
   steps:
   - script: |
       docker build -f Dockerfile.build -t $(dockerId)/dotnetcore-build:$BUILD_BUILDID .
       docker run --name dotnetcoreapp --rm -d $(dockerId)/dotnetcore-build:$BUILD_BUILDID
       docker cp dotnetcoreapp:app/dotnetcore-tests/TestResults $(System.DefaultWorkingDirectory)
       docker cp dotnetcoreapp:app/dotnetcore-sample/out $(System.DefaultWorkingDirectory)
       docker stop dotnetcoreapp
   
   - task: PublishTestResults@2
     inputs:
       testRunner: VSTest
       testResultsFiles: '**/*.trx'
       failTaskOnFailedTests: true
   
   - script: |
       docker build -f Dockerfile -t $(dockerId)/dotnetcore-sample:$BUILD_BUILDID .
       docker login -u $(dockerId) -p $pswd
       docker push $(dockerId)/dotnetcore-sample:$BUILD_BUILDID
     env:
       pswd: $(dockerPassword)
   

   Wenn Sie alternativ eine Azure Container Registry konfigurieren und das Image per Push in diese Registrierung übertragen möchten, ersetzen Sie den Inhalt der Datei .vsts-ci.yml durch Folgendes:

   # Build Docker image for this app to be published to Azure Container Registry
   pool:
     vmImage: 'ubuntu-latest'
   variables:
     buildConfiguration: 'Release'
   
   steps:
   - script: |
       docker build -f Dockerfile.build -t $(dockerId)/dotnetcore-build:$BUILD_BUILDID .
       docker run --name dotnetcoreapp --rm -d $(dockerId)/dotnetcore-build:$BUILD_BUILDID
       docker cp dotnetcoreapp:app/dotnetcore-tests/TestResults $(System.DefaultWorkingDirectory)
       docker cp dotnetcoreapp:app/dotnetcore-sample/out $(System.DefaultWorkingDirectory)
       docker stop dotnetcoreapp
   
   - task: PublishTestResults@2
     inputs:
       testRunner: VSTest
       testResultsFiles: '**/*.trx'
       failTaskOnFailedTests: true
   
   - script: |
       docker build -f Dockerfile -t $(dockerId).azurecr.io/dotnetcore-sample:$BUILD_BUILDID .
       docker login -u $(dockerId) -p $pswd $(dockerid).azurecr.io
       docker push $(dockerId).azurecr.io/dotnetcore-sample:$BUILD_BUILDID 
     env:
       pswd: $(dockerPassword)
   

2. Pushen Sie die Änderung an den Mainbranch in Ihrem Repository.

3. Wenn Sie Azure Container Registry verwenden, stellen Sie sicher, dass Sie im Azure-Portal die Registrierung vorab erstellt haben. Kopieren Sie den Benutzernamen und das Kennwort der Administratorin/des Administrators, die im Abschnitt Zugriffsschlüssel der Registrierungseinstellungen im Azure-Portal angezeigt werden.

4. Aktualisieren Sie Ihre Buildpipeline wie folgt:

   • Agent-Pool: Hosted Ubuntu 1604
     • dockerId: Legen Sie den Wert auf Ihre Docker-ID für DockerHub oder den Administratorbenutzernamen für Azure Container Registry fest.
     • dockerPassword: Legen Sie den Wert auf Ihr Kennwort für DockerHub oder das Administratorkennwort für Azure Container Registry fest.
   • YAML-Dateipfad: /.vsts-ci.docker.yml

5. Stellen Sie einen neuen Build in eine Warteschlange, und beobachten Sie, wie er ein Docker-Image erstellt und an Ihre Registrierung pusht und die Testergebnisse an Azure DevOps pusht.

Klassisch

1. Erstellen Sie eine neue Buildpipeline mit dem Leeren Auftrag.

2. Wählen Sie im Buildpipeline-Editor auf der Seite Aufgaben die Option Pipeline aus, und bearbeiten Sie die Eigenschaften wie folgt.

   • Agent-Warteschlange: Hosted Ubuntu 1604

3. Fügen Sie eine Bash-Aufgabe hinzu, und konfigurieren Sie sie wie folgt, um Artefakte zu erstellen und auf den Host zu kopieren:

   • Typ: Inline

   • Skript: Verwenden Sie zum Erstellen und Testen von Artefakten sowie Kopieren auf den Host das folgende Skript:

     docker build -f Dockerfile.build -t $(dockerId)/dotnetcore-build:$BUILD_BUILDID .
     docker run --name dotnetcoreapp --rm -d $(dockerId)/dotnetcore-build:$BUILD_BUILDID
     docker cp dotnetcoreapp:app/dotnetcore-tests/TestResults $(System.DefaultWorkingDirectory)
     docker cp dotnetcoreapp:app/dotnetcore-sample/out $(System.DefaultWorkingDirectory)
     docker stop dotnetcoreapp
     

4. Fügen Sie eine Aufgabe Testergebnisse veröffentlichen hinzu, um Ergebnisse in der Pipeline zu veröffentlichen, und bearbeiten Sie ihre Eigenschaften wie folgt:

   • Testergebnisformat: VSTest
   • Testergebnisdateien: **/*.trx

5. Fügen Sie eine Bash-Aufgabe hinzu, um das endgültige Image im Repository zu veröffentlichen, und bearbeiten Sie seine Eigenschaften wie folgt:

   • Typ:Inline

   • Skript:

     • Verwenden Sie zum Pushen an Docker Hub das folgende Skript:

       docker build -f Dockerfile -t $(dockerId)/dotnetcore-sample:$BUILD_BUILDID .
       docker login -u $(dockerId) -p $(dockerPassword)
       docker push $(dockerId)/dotnetcore-sample:$BUILD_BUILDID
       

     • Verwenden Sie zum Pushen an Azure Container Registry das folgende Skript:

       docker build -t $(dockerId).azurecr.io/dotnetcore-sample:$BUILD_BUILDID . 
       docker login -u $(dockerId) -p $(dockerPassword) $(dockerId).azurecr.io 
       docker push $(dockerId).azurecr.io/dotnetcore-sample:$BUILD_BUILDID
       

6. Wenn Sie Azure Container Registry verwenden, stellen Sie sicher, dass Sie im Azure-Portal die Registrierung vorab erstellt haben. Kopieren Sie den Benutzernamen und das Kennwort des Administrators, die im Abschnitt Zugriffsschlüssel der Registrierungseinstellungen im Azure-Portal angezeigt werden.

7. Definieren Sie auf der Registerkarte Variablen der Buildpipeline zwei Variablen:

   • dockerId: Legen Sie den Wert auf Ihre Docker-ID für DockerHub oder den Administratorbenutzernamen für Azure Container Registry fest.
   • dockerPassword: Legen Sie den Wert auf Ihr Kennwort für DockerHub oder das Administratorkennwort für Azure Container Registry fest, und markieren Sie ihn als sicher.

8. Speichern Sie die Pipeline, und reihen Sie einen Build in die Warteschlange ein. Beobachten Sie, wie er ein Docker-Image erstellt und an Ihre Registrierung pusht und die Testergebnisse an Azure DevOps pusht.

Anforderungen

Anforderung	BESCHREIBUNG
Pipelinetypen	YAML, Klassischer Build, klassisches Release
Wird ausgeführt auf	Agent, DeploymentGroup
Forderungen	Keine
Capabilities	Diese Aufgabe erfüllt keine Anforderungen an nachfolgende Aufgaben im Auftrag.
Befehlseinschränkungen	Any
Setzbare Variablen	Any
Agent-Version	2.0.0 oder höher
Aufgabenkategorie	Testen