Freigeben über


Azure Pipelines – Sprint 194 Update

Features

Veröffentlichen des neutralen Status auf GitHub, wenn ein Build übersprungen wird

Mit Azure Pipelines können Sie immer eine Pullanforderung in GitHub überprüfen. Sie können auch angeben, welche Pfade in Ihrem GitHub-Repository eine Pipeline auslösen sollen. Die folgende Pipeline wird beispielsweise ausgelöst, wenn eine Änderung in den code Branch auf der main Zweig gepusht wird, aber nicht ausgelöst, wenn eine Änderung in den docs Ordner gepusht wird.

trigger: none

pr:
 branches:
   include:
     - main
 paths:
   include:
     - code
   exclude:
     - docs

pool:
  vmImage: ubuntu-latest

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

Nach Abschluss der Pipeline würde Azure Pipelines einen Status zurück auf GitHub posten. Wenn Branch-Schutzrichtlinien für Ihr GitHub-Repository wirksam waren, bestimmt der von Azure Pipelines gepostete Status, ob die Pullanforderung zusammengeführt werden würde.

Wenn Sie im obigen Beispiel eine Änderung an docs vorgenommen haben, blockiert GitHub derzeit die Pull-Anfrage, bis ein Status von Azure Pipelines zurückgegeben wird. Azure Pipelines führt jedoch keinen Überprüfungsbuild aus, da dieser Pfad vom Trigger ausgeschlossen ist, sodass die Pullanforderung nicht abgeschlossen werden kann. Kunden, die Pfadausschluss-Auslöser oder mehrere Pipelines für ein einzelnes GitHub-Repository einrichten, stehen häufig vor dieser Herausforderung.

In Zukunft wird Azure Pipelines einen neutral-Status an GitHub zurückmelden, wenn entschieden wird, aufgrund einer Pfadausschlussregel keinen Validierungsbuild auszuführen. Dies stellt eine klare Richtung zu GitHub bereit, die angibt, dass Azure Pipelines die Verarbeitung abgeschlossen hat.

Konversationsansicht

Unterhaltungsansicht

Details überprüfen:

Details überprüfen

Der Zugriff auf alle Pipelines ist in geschützten Ressourcen standardmäßig deaktiviert

Eine YAML-Pipeline kann sich auf eine oder mehrere geschützte Ressourcen verlassen. Dienstverbindungen, Agentpools, variable Gruppen, sichere Dateien und Repositorys sind beispiele für geschützte Ressourcen, da ein Administrator einer solchen Ressource steuern kann, welche Pipelines Zugriff auf diese Ressource haben. Administratoren verwenden den Bereich "Sicherheitseinstellungen" der Ressource, um Pipelines zu aktivieren oder zu deaktivieren.

Wenn Sie eine dieser Ressourcen erstellen, gewährt die Standardoberfläche Zugriff auf alle Pipelines, es sei denn, Sie deaktivieren sie explizit. Um den gesamtsicherheitsstatus zu verbessern, wird der Standardwert so festgelegt, dass der Zugriff auf alle Pipelines verweigert wird. Um Zugriff auf alle Pipelines zu gewähren, aktivieren Sie einfach den Umschalter in der Erstellungsumgebung oder nach dem Erstellen der Ressource.

Neue Azure-Dienstverbindung

Einfügen einer Aufgabe vor oder nach angegebenen Zielaufgaben mithilfe eines Dekorators

Dekoratoren sind eine Möglichkeit, Aufgaben automatisch in eine Pipeline einzufügen. Sie werden häufig von zentralen Teams in einer Organisation verwendet, um die erforderlichen Compliance-Verfahren automatisch auszuführen. Dekoratoren können mit klassischen Builds, klassischen Releases oder YAML-Pipelines verwendet werden.

Derzeit kann eine Aufgabe am Anfang jedes Auftrags, am Ende jedes Auftrags oder direkt nach einem Auscheckvorgang durch einen Dekorateur eingefügt werden. Um dies zu steuern, geben Sie einen target im Beitragsbereich der Erweiterung des Dekorators an, wie hier beschrieben. Wir erweitern nun die Liste der Ziele, um Folgendes einzuschließen:

ms.azure-pipelines-agent-job.pre-task-tasks
ms.azure-pipelines-agent-job.post-task-tasks
ms.azure-release-pipelines-agent-job.pre-task-tasks
ms.azure-release-pipelines-agent-job.post-task-tasks

Hier ist ein Beispiel für einen Dekorateur, der eine Aufgabe vor jeder Instanz eines PublishPipelineArtifacts Vorgangs in eine Pipeline einjiziert.

{
    "manifestVersion": 1,
    "contributions": [
        {
            "id": "my-required-task",
            "type": "ms.azure-pipelines.pipeline-decorator",
            "targets": [
                "ms.azure-pipelines-agent-job.pre-task-tasks"
            ],
            "properties": {
                "template": "my-decorator.yml",
                "targettask": "ECDC45F6-832D-4AD9-B52B-EE49E94659BE"
            }
        }
    ],
    "files": [
        {
            "path": "my-decorator.yml",
            "addressable": true,
            "contentType": "text/plain"
        }
    ]
}

Ankündigung eines veralteten Zeitplans für gehostete Windows 2016-Images

Kürzlich haben wir Windows 2022 als gehostetes Image verfügbar gemacht. Mit dem bevorstehenden Ende des Mainstream-Supports für Windows 2016 im Januar 2022 werden vs2017-win2016 Bilder ab dem 15. November eingestellt. Die vollständige Ausmusterung dieses Bilds ist für März 2022 geplant. Da es sich um ein häufig verwendetes Bild handelt, wollten wir Ihnen genügend Benachrichtigungen und Zeit geben, um notwendige Änderungen an Ihren Pipelines vorzunehmen.

In unserem Blogbeitrag erfahren Sie, wie Sie alle Projekte und Pipelines mit dem gehosteten Windows 2016-Image finden und wie Sie zu neueren Versionen migrieren können.

Ankündigung der Veralterung von gehosteten macOS 10.14-Images

Kürzlich haben wir macOS-11 als gehostetes Image zur Verfügung gestellt. Daher wird das macOS-10.14-Image im Dezember 2021 eingestellt. Builds, die auf diesem Image basieren, schlagen fehl, sobald es veraltet ist. Weitere Details zur Veraltetkeit verschiedener Bilder finden Sie in unserem Blogbeitrag.

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.