Freigeben über

NuGet-, npm- und andere Artifacts-Tasks unterstützen Proxys – Sprint 147 Update

  • Artikel

Im Sprint 147-Update von Azure DevOps haben wir die verschiedenen artefaktbezogenen Pipelineaufgaben aktualisiert, um Proxys zu unterstützen. Mit diesem Update arbeiten Proxys jetzt in den Aufgaben npm, NuGet, .NET Core und Universal Packages.

Weitere Informationen finden Sie weiter unten in der Liste Features .

Features

Allgemeines:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Artifacts:

Berichterstellung:

Wiki:

Allgemein

Alle Benutzer jetzt in der neuen Navigation

Mit diesem Sprint wurden alle Benutzer in die neue Navigation verschoben. Wir haben den Umschalter für die Vorschaufunktion entfernt, mit dem Benutzer zum vorherigen Navigationsmodell zurückkehren können. Weitere Informationen zum Navigieren im Webportal finden Sie unter Webportalnavigation in Azure DevOps.

Azure Boards

Anzeigen status von Arbeitselementen in #ID Erwähnungen

Um das Erwähnen von Arbeitselementen zu verbessern, haben wir weitere Informationen hinzugefügt, wenn Sie ein Arbeitselement mithilfe von #ID verknüpfen. Nun wird im Diskussionsabschnitt die status des Arbeitselements angezeigt, das Sie neben der ID, dem Titel und dem Arbeitselementtyp verknüpft haben.

Arbeitselement status anzeigen.

Diese Erfahrung kann auch auf Wiki-Seiten verwendet werden, wie hier beschrieben, sowie in Pull Request-Kommentaren. Weitere Informationen finden Sie in der Dokumentation zur Verwendung von #ID, um einen Link zu Arbeitselementen zu erstellen.

Azure Repos

Anzeigen nur der linken oder rechten Datei in einem Pull Request

Beim Anzeigen von Dateiänderungen in einem Pull Request können Sie heute entweder einen parallelen diff oder einen Inlinemodus diff verwenden. Wir haben das Feedback erhalten, dass viele von Ihnen nur die Originaldatei oder die geänderte Datei sehen möchten, ohne sie zu vergleichen. Daher haben wir eine neue Option hinzugefügt, mit der Sie entweder die linke Oder die rechte Datei einzeln anzeigen können.

Zeigen Sie nur die linke oder rechte Datei in einem Pull Request an.

Azure Pipelines

Wiederherstellen gelöschter Releasepipelines

Das Löschen nicht verwendeter Releasepipelines hilft dabei, die Liste der Releasepipeline sauber zu behalten, aber manchmal löschen Sie versehentlich etwas. Mit diesem Update ist es jetzt möglich, eine Releasepipeline wiederherzustellen, die innerhalb der letzten 30 Tage gelöscht wurde. Im linken Bereich der Seite Releases wurde eine neue Registerkarte hinzugefügt, die eine Liste der gelöschten Releasepipelines anzeigt. In dieser Ansicht können Sie eine gelöschte Releasepipeline wiederherstellen, indem Sie die Pipeline aus der Liste auswählen und auf die Schaltfläche Wiederherstellen klicken.

Stellen Sie gelöschte Releasepipelines wieder her.

YAML-Dateien für eine neue Pipeline werden von Ihrer Identität und nicht von unserem Bot committet.

Beim Erstellen einer Pipeline committen Azure Pipelines optional eine YAML-Datei in Ihr Repository und erstellt dann einen Pull Request für die Pipeline. Wenn sich das Repository zuvor auf GitHub befand und sie die Azure Pipelines-GitHub-App installiert hatten, wurden der Commit und der Pull Request vom GitHub-App "Azure Pipelines [bot]" erstellt. Mit diesem Update wird Ihre GitHub-Identität als Ersteller der Pipeline anstelle der GitHub-App angezeigt.

Erstellen von Pipelines aus einer vorhandenen YAML-Datei in einem beliebigen Branch oder Pfad

Derzeit erkennt Azure Pipelines beim Erstellen einer neuen Pipeline eine vorhandene YAML-Datei namens azure-pipelines.yml oder .azure-pipelines.yml im Stammverzeichnis Ihres Repositorys im Standardbranch und verwendet sie automatisch. Mit diesem Update können Sie eine vorhandene Azure Pipelines-YAML-Datei mit einem anderen Namen oder Pfad oder in einem nicht Standardbranch auswählen.

Um eine vorhandene Datei auszuwählen, wählen Sie auf der Konfigurationsseite Des Assistenten für neue Buildpipelinesdie Option Vorhandene Azure Pipelines-YAML-Datei aus. Wählen Sie dann den Branch aus, und navigieren Sie, um den YAML-Dateipfad auszuwählen.

Erstellen Sie Pipelines aus einer vorhandenen YAML-Datei in einem beliebigen Branch oder Pfad.

Ausführen von Pipelines mithilfe von GitHub-Pull Request-Kommentaren

Mit diesem Update können Sie eine Pipeline oder Testsammlung ausführen, um einen GitHub-Pull Request aus dem Kommentarabschnitt dieses PR zu überprüfen. Jeder Besitzer oder Mitarbeiter kann einen Pull Request mit /AzurePipelines run oder /AzurePipelines run <pipeline_name> kommentieren, um einen Build auszulösen.

Sie können den /AzurePipelines Moniker auch als /azpkürzen. Weitere Informationen zu diesem Feature finden Sie /azp help im Kommentar.

Ausführen von Pipelines mithilfe von GitHub-Pull Request-Kommentaren.

Beschränken von Pull Request-Validierungsbuilds auf autorisierte Teammitglieder

Es ist eine bewährte Methode, die Qualität eines Branchs zu schützen, indem Pull Request-Validierungsbuilds implementiert werden. Bisher wurden diese Validierungsbuilds automatisch von jedem GitHub-Pull Request ausgelöst, was riskant sein kann, da der Build ohne Ihre Überprüfung gestartet wird.

Mit diesem Update können Sie die Autorisierung von Pull Request-Validierungsbuilds durch Ihr Team anfordern. Wählen Sie hierzu die Registerkarte Trigger in den Einstellungen Ihrer Pipeline aus. Aktivieren Sie dann unter Pull Request-Validierung die Option Nur Triggerbuilds für Pull Request-Kommentare von Projektmitarbeitern , und speichern Sie die Pipeline.

Jetzt werden Pull Request-Validierungsbuilds nicht automatisch ausgelöst. Jeder Repositorybesitzer oder Mitwirkender kann einen Validierungsbuild auslösen, indem er den Pull Request mit /AzurePipelines run oder /AzurePipelines run <pipeline_name>kommentiert.

Beschränken Sie Pull Request-Validierungsbuilds auf autorisierte Teammitglieder.

Veröffentlichen von Buildartefakten mit langen Dateipfaden

Bisher gab es eine Einschränkung, die das Hochladen von Buildartefakten mit Pfaden mit mehr als 233 Zeichen verhinderte. Dies könnte verhindern, dass Sie Code Coverage-Ergebnisse aus Linux- und macOS-Builds hochladen, deren Dateipfade länger als der Grenzwert sind. Mit diesem Update haben wir den Grenzwert erweitert, um lange Pfade zu unterstützen.

Neue Erweiterungsbeitragspunkte auf der Registerkarte "Pipelines-Test"

Mit diesem Sprint haben wir das Erweiterungsframework weiter leistungsfähiger, indem wir zwei neue Beitragspunkte auf der Registerkarte Testergebnisse in Pipelines hinzugefügt haben. Dadurch können Marketplace-Erweiterungen maßgeschneiderte Berichterstattungsfunktionen bereitstellen und weitere Interaktivität hinzufügen.

Die beiden Beitragspunkte sind:

  1. Schaltfläche "Benutzerdefinierte Aktion" in der Symbolleiste

    Manchmal möchten Sie möglicherweise eine Aktion ausführen, z. B. das Aktualisieren der Daten einer API oder das Ausführen benutzerdefinierter Tools mithilfe von Metadaten aus Ihren Testergebnissen. Mit diesem Beitragspunkt können Sie Erweiterungen erstellen, die den unmittelbaren Kontext des ausgewählten Testergebnisses verwenden, um der Schaltfläche *Benutzerdefinierte Aktion- eine benutzerdefinierte Aktion hinzuzufügen.

    Schaltfläche

  2. Registerkarte "Benutzerdefinierte Details" im Detailbereich

    Möglicherweise verfügen Sie über eine Vielzahl von Testberichtsverbrauchsworkflows und möchten möglicherweise verschiedene Datenpunkte für fehlgeschlagene Tests zum Debuggen und zur Analyse anzeigen. Mithilfe dieses Beitragspunkts kann Ihr Team dem Detailbereich eine neue Registerkarte hinzufügen, die angezeigt wird, wenn Sie eine beliebige Testergebniszeile im Datenraster auswählen. Diese neue Registerkarte kann eine Ansicht mit statischem Inhalt oder dynamischen Daten anzeigen, die mithilfe interner oder externer APIs abgerufen werden.

Azure Artifacts

Bisher boten viele Artefakt-bezogene Buildtasks keine vollständige Unterstützung für die Proxyinfrastruktur von Azure Pipelines, was zu Herausforderungen bei der Verwendung der Aufgaben von lokalen Agents führte. Mit diesem Update haben wir den folgenden Aufgaben Unterstützung für Proxys hinzugefügt:

Delegieren, wer Feeds verwalten kann

In Azure Artifacts konnten Project Collection Administrators (PCAs) immer alle Feeds in einer Azure DevOps-organization verwalten. Mit diesem Update können PCAs diese Möglichkeit auch anderen Benutzern und Gruppen geben und so die Möglichkeit delegieren, jeden Feed zu verwalten.

Berichterstellung

Testergebnistrend (Erweitert) Widget

Das Widget Test results trend (Advanced) ist jetzt für diejenigen verfügbar, die die Analytics-Erweiterung auf ihrem Azure DevOps-organization installiert haben. Sie bietet nahezu echtzeitbasierte Einblicke in Ihre Testdaten für mehrere Builds und Releases. Das Widget Testergebnistrend (Erweitert) zeigt einen Trend Ihrer Testergebnisse für Ihre Pipelines oder pipelineübergreifend an. Sie können es verwenden, um die tägliche Anzahl der Tests, die Bestandensrate und die Testdauer nachzuverfolgen. Die Überwachung der Testqualität im Lauf der Zeit und die Verbesserung der Testsicherheit ist der Schlüssel für die Aufrechterhaltung einer fehlerfreien DevOps-Pipeline.

Testergebnistrend (Erweitert) Widget.

Das Widget Test results trend (Advanced) hilft Ihnen, Ausreißer in Ihren Testergebnissen zu ermitteln und Fragen wie: Dauert die Ausführung von Tests länger als üblich? Welche Testdatei oder Pipeline wirkt sich auf meine Gesamtdurchlaufrate aus? Was sind meine Tests mit langer Ausführungszeit?

Um diese Fragen zu beantworten, bietet das Widget die folgenden Features:

  • Zeigt einen Trend der Bestandensrate und die Anzahl der Testergebnisse oder die Testdauer an.
  • Zeigt Testergebnisse basierend auf mehreren Buildpipelines oder Releasepipelines an
  • Verwendet kombinierte Diagrammoptionen, um zwei Metriken für denselben Trend anzuzeigen
  • Filtert die Testanzahl im Zeitverlauf nach Testergebnis
  • Filtert alle Testergebnisse nach Branch oder Test
  • Stapelt Ihre Metriken nach Testattributen wie Priorität oder Umgebung
  • Gruppierung Ihrer Daten in Testdateien, Besitzern oder Pipelines

Das Widget ist hochgradig konfigurierbar, sodass Sie es für eine Vielzahl von Szenarien verwenden können.

Wiki

Bisher sind freigegebene Wiki-Seitenlinks nicht mehr vorhanden, wenn die verknüpfte Seite umbenannt oder verschoben wurde. Mit diesem Update haben wir permanente Links eingeführt, indem wir der URL eine Seiten-IDs hinzugefügt haben. Dadurch wird sichergestellt, dass die von Ihnen freigegebenen Links im Laufe der Zeit unverändert bleiben.

Dieses Feature wurde basierend auf einem Vorschlagsticket priorisiert.

Anzeigen status von Arbeitselementen auf Wiki-Seiten

In diesem Update haben wir die Erwähnungen von Arbeitselementen auf Wiki-Seiten verbessert, indem wir der Seite die status des Arbeitselements zusammen mit der ID und dem Titel hinzugefügt haben.

Anzeigen von Arbeitselementen status auf Wiki-Seiten.

Arbeitselementverweise in Pull Request-Kommentaren und Boards-Diskussionen zeigen auch die status an.

Dieses Feature hat aufgrund eines Vorschlags Priorität erhalten.

Nächste Schritte

Hinweis

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

Wechseln Sie zu Azure DevOps, und sehen Sie sich an.

Navigieren Sie zu Azure DevOps.

Senden von Feedback

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

Einen Vorschlag unterbreiten

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

Vielen Dank,

Alex Mullans