Azure Pipelines – Sprint 195 Update

Features

Automatische Wiederholversuche für eine Aufgabe

Wenn Sie eine instabile Aufgabe haben, die innerhalb einer Pipeline zeitweise fehlschlägt, müssen Sie die Pipeline möglicherweise erneut ausführen, um einen erfolgreichen Abschluss zu erreichen. In den meisten Fällen empfiehlt es sich, eine unzuverlässige Aufgabe oder ein Skript zu beheben, indem Sie es direkt korrigieren. Wenn ihre Testaufgabe beispielsweise aufgrund von flackerigen Tests in einer Pipeline fehlschlägt, empfiehlt es sich immer, die flackerigen Tests zu beheben und sie zuverlässiger zu machen. Wenn Ihr Skript gelegentlich fehlschlägt, sollte das Skript besser verbessert werden, indem beispielsweise Wiederholungen eingeführt werden.

Es gibt jedoch einige Fälle, in denen Sie die Aufgabe möglicherweise erneut versuchen möchten. Ein gängiger Anwendungsfall hierfür ist eine Aufgabe, die ein Paket herunterlädt (z. B. NuGet, npm usw.). Wir haben häufig festgestellt, dass diese Aufgaben anfällig für Netzwerkfehler und die vorübergehenden Fehler auf den Pakethostingservern sind. Wir haben Ihr Feedback gehört, dass es besser wäre, solche fehlerhaften Aufgaben automatisch erneut zu wiederholen, ohne die gesamte Pipeline erneut starten zu müssen.

Basierend auf Ihrem Feedback haben wir ein Feature hinzugefügt, um eine Aufgabe in einer Pipeline automatisch erneut zu versuchen, wenn ein Fehler auftritt. Wenn Sie YAML-Pipelines verwenden, können Sie diese Eingabe wie folgt festlegen:

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Wenn Sie klassische Build- oder Freigabepipelinen verwenden, können Sie diese Eigenschaft unter den Steuerelementoptionen für die Aufgabe festlegen.

Im Folgenden sind einige Punkte zu beachten, wenn Sie Wiederholungsversuche verwenden:

  • Der fehlerhafte Vorgang wird sofort erneut ausgeführt.
  • Es gibt keine Annahme über die Idempotenz der Aufgabe. Wenn der Vorgang Nebenwirkungen hat (z. B. wenn er eine externe Ressource teilweise erstellt hat), schlägt der Vorgang möglicherweise das zweite Mal fehl, wenn er ausgeführt wird.
  • Es gibt keine Informationen über die Wiederholungsanzahl, die der Aufgabe zur Verfügung gestellt wurde.
  • Der Vorgangsprotokolle wird eine Warnung hinzugefügt, die angibt, dass sie fehlgeschlagen ist, bevor sie erneut versucht wird.
  • Alle Versuche, eine Aufgabe erneut zu versuchen, werden in der Benutzeroberfläche als Teil desselben Aufgabenknotens angezeigt.

Hinweis

Erfordert Agent Version 2.194.0 oder höher. Wird für agentlose Aufgaben nicht unterstützt.

Nutzen von Eingaben aus einer anderen Aufgabe in einem Dekorateur

Wir haben kürzlich ein Feature hinzugefügt, um einen Vorgang automatisch in eine Pipeline einzufügen, bevor eine andere Zielaufgabe in dieser Pipeline ausgeführt wird. Wir verbessern nun dieses Feature, indem Sie die eingefügte Aufgabe mithilfe der Eingabeparameter der Zielaufgabe anpassen können. Die Syntax zum Schreiben eines Dekorators hierfür lautet wie folgt:

{
    "contributions": [
        {
            "id": <my-required-task>,
            "type": "ms.azure-pipelines.pipeline-decorator",
            "targets": [
                "ms.azure-pipelines-agent-job.pre-task-tasks",
                "ms.azure-pipelines-agent-job.post-task-tasks"
            ],
            "properties": {
                "template": "my-decorator.yml",
                "targettask": <target-task-id>,
                "targettaskinputs": ["<name of input>"]
            }
        }
    ],
    ...
}

Dieses Feature funktioniert nur, wenn Sie pre-task-tasks oder post-task-tasks als Ziel für die Einfügung auswählen und targettask im Eigenschaftenabschnitt der Komponente angeben. Anschließend können Sie eine zusätzliche Eigenschaft namens targettaskinputs hinzufügen und eine Liste der Eingabeparameter angeben, die von der Zielaufgabe akzeptiert werden. Diese Eingaben werden nun der eingespeisten Aufgabe zur Verfügung gestellt.

Ein gängiger Anwendungsfall, der durch ein solches Szenario erreicht werden kann, ist wie folgt. Angenommen, Sie möchten eine Aufgabe einfügen, die automatisch den Namen des Artefaktes protokolliert, das von einem Build veröffentlicht wird. Der Name des Artefakts ist eine Eingabe für die PublishBuildArtifacts Aufgabe. Ihre eingefügte Aufgabe kann nun denselben Eingabeparameter abrufen und für die Protokollierung verwenden.

Verbesserungen der Nutzungshistorie von Dienstanschlüssen

Wenn eine Pipeline eine Dienstverbindung verwendet, wird diese Verwendung im Verlauf der Verbindung protokolliert. Administratoren der Dienstverbindung können den Verwendungsverlauf überprüfen, indem Sie zu Projekteinstellungen navigieren und die entsprechende Dienstverbindung auswählen. Es gab einige Probleme mit dem Verwendungsverlauf von Dienstverbindungen, die mit diesem Update behoben wurden. Korrekturen umfassen Folgendes:

  • Wenn eine Dienstverbindung in einem Bereitstellungsauftrag (anstelle eines regulären Auftrags) verwendet wird, wurde diese Verwendung nicht protokolliert.
  • Wenn Sie mehrere Dienstverbindungen in mehreren Phasen einer Pipeline verwendet haben, würden alle Dienstverbindungen einen Datensatz im Nutzungsverlauf anzeigen, obwohl einige der Phasen übersprungen wurden.

Die Standard-Agent-Spezifikation für klassische Pipelines ist jetzt Windows-2019

In den letzten Versionshinweisen haben wir einen Ausmusterungsfahrplan für vs2017-win2016 gehostete Bilder angekündigt. In Vorbereitung darauf ändern wir nun die Standard-Agent-Spezifikation für neue Pipelines in klassischen Pipelines zu windows-2019.

Agentspezifikation

Nächste Schritte

Hinweis

Diese Features werden in den nächsten zwei bis drei Wochen eingeführt.

Gehen Sie zu Azure DevOps und schauen Sie sich an.

So geben Sie Feedback

Wir würden uns freuen zu hören, was Sie über diese Features denken. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Vorschlag erstellen

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.