Unterstützung für Wildcards und bedingte Ausdrücke in YAML-Pipelinedateien

  • Artikel

In diesem Sprint haben wir Unterstützung für Wildcards und bedingte Ausdrücke für YAML-Pipelinedateien eingeschlossen. Darüber hinaus haben wir mehrere Aktualisierungen an den von Azure Pipelines gehosteten Images vorgenommen.

Ausführliche Informationen finden Sie in den folgenden Featurebeschreibungen.

Azure Pipelines

Azure Repos

Azure Pipelines

Neue bedingte YAML-Ausdrücke

Das Schreiben von bedingten Ausdrücken in YAML-Dateien wurde mit der Verwendung von ${{ else }} und ${{ elseif }} Ausdrücken noch einfacher. Im Folgenden finden Sie Beispiele für die Verwendung dieser Ausdrücke in YAML-Pipelinesdateien.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux') }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Unterstützung für Platzhalter in Pfadfiltern

Wildcards können verwendet werden, wenn Sie Ein- und Ausschlusszweige für CI- oder PR-Trigger in einer YaML-Pipelinedatei angeben. Sie können jedoch nicht verwendet werden, wenn Pfadfilter angegeben werden. Sie können beispielsweise nicht alle Pfade einschließen, die übereinstimmen src/app/**/myapp*. Dies wurde von mehreren Kunden als Unannehmlichkeiten herausgestellt. Dieses Update füllt diese Lücke. Jetzt können Sie beim Angeben von Pfadfiltern Wildcardzeichen (**, *oder ?) verwenden.

Unterstützung für mehrere Status in Bitbucket

Azure Pipelines sind in Bitbucket-Repositorys integriert und unterstützen CI- und PR-Trigger. Sie können mehrere Pipelines aus einem einzelnen Bitbucket-Repository einrichten. Nach Abschluss dieser Pipelines konnten Sie jedoch nur einen Status in Bitbucket sehen. Wir haben Feedback von der Entwicklercommunity gehört, um den Status jeder Pipeline separat in Bitbucket anzuzeigen. Mit diesem Update haben wir unsere API-Aufrufe an Bitbucket aktualisiert und zusätzliche Informationen zum Namen der Pipeline übergeben.

Buildstatus

Suche nach PR-Kommentaren vor der Buildvalidierung durch Mitwirkende überspringbar

Wenn Sie Azure Pipelines mit GitHub-Repositorys verwenden, empfehlen wir, dass Sie keine PR-Validierungspipeline für Beiträge ausführen, die von einem Verzweigungsrepository erhalten wurden. Die bewährte Methode besteht darin, zuerst einen der Mitarbeiter des Repositorys zu überprüfen, die Änderung zu überprüfen und dann einen Kommentar zur PR hinzuzufügen, um die Pipeline auszulösen. Sie können diese Einstellungen konfigurieren, indem Sie im Pipelineweb-Editor das Menü "Triggers" (für YAML-Pipelines) oder die Registerkarte "Trigger" (für klassische Buildpipelinen) auswählen. Anstatt jede PR aus einer Verzweigung zuerst von einem Teammitglied zu überprüfen, können Sie diese Richtlinie auch nur für Beiträge erzwingen, die von Nicht-Teammitgliedern stammen.

Mit diesem Update können Sie die Suche nach einem PR-Kommentar von Beiträgen überspringen, die von allen Mitwirkenden erhalten wurden. Wenn Sie als Nicht-Teammitglied eine Verzweigung erstellen und eine PR für den Upstream erstellen, werden Sie erst dann als Mitwirkender am Upstream-Repository betrachtet, wenn Ihre PR zusammengeführt wird. Sobald Ihre PR zusammengeführt wurde, werden Sie als Mitwirkender betrachtet. Wenn sie die unten gezeigte neue Option auswählen, wenn ein Nicht-Teammitglied eine PR aus einer Verzweigung zum ersten Mal einreicht, müsste jemand in Ihrem Team die PR überprüfen und einen Kommentar hinzufügen, um die Pipeline auszulösen. Aber sobald die PR zusammengeführt wird, werden alle weiteren Beiträge dieses Nicht-Teammitglieds die Pipeline direkt auslösen, ohne auf einen PR-Kommentar zu warten.

Anfordern des Kommentars eines Teammitglieds vor dem Erstellen einer Pullanforderung

Windows Server 2022 mit Visual Studio 2022 jetzt auf von Microsoft gehosteten Agents (Vorschauversion) verfügbar

Windows Server 2022 und Visual Studio Enterprise 2022 Preview sind jetzt in der Vorschau auf von Microsoft gehosteten Agents verfügbar. Sie können es verwenden, indem Sie in Ihrer Pipeline als Bild verweisen windows-2022 .

pool:
  vmImage: 'windows-2022'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '**/*.sln'
- task: VSBuild@1 # Visual Studio 2022 build
  inputs:
    solution: '**/*.sln'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: 'Any CPU'
    configuration: 'Release'

Wenn Sie auf windows-latest pool in Ihren YAML-Pipelines verweisen, bedeutet dies weiterhin Windows-2019 und nicht Windows-2022, während sich letztere in der Vorschau befindet.

Das Windows Server 2022-Pipelineimage verfügt über unterschiedliche Tools und Toolversionen im Vergleich zu Windows Server 2019. Sie können die Details im Problem mit der Softwareankündigung und im Dokumentations-Repository für virtuelle Umgebungen anzeigen.

Allgemeine Verfügbarkeit von macOS 11 für von Microsoft gehostete Agents

macOS 11 ist jetzt allgemein für von Microsoft gehostete Agents verfügbar. Sie können es verwenden, indem Sie in Ihrer Pipeline als Bild verweisen macos-11 .

pool:
  vmImage: macos-11

Entfernen des Ubuntu 16.04-Images auf von Microsoft gehosteten Agents

Wie bereits angekündigt, entfernen wir am 20. September 2021 Ubuntu 16.04 Image von von Microsoft gehosteten Agents. Traditionelle 5-Jährige Unterstützung von Ubuntu 16.04 von Canonical endete im April 2021. Sie müssen Ubuntu-16.04-Pipelines zu ubuntu-18.04 oder ubuntu-latest migrieren, die auf Ubuntu 20.04 LTS ausgeführt wird.

Builds, die Ubuntu-16.04 verwenden, verfügen bereits über eine Warnung, in der sie protokolliert werden. Um sicherzustellen, dass jeder über diese Änderung informiert ist, haben wir 2 kurze "Brownouts" geplant. Ubuntu 16.04-Builds schlagen während des Brownoutzeitraums fehl. Daher wird empfohlen, Ihre Workflows vor dem 6. September 2021 zu migrieren.

Die Brownouts werden für die folgenden Datums- und Uhrzeitangaben geplant (Beachten Sie, dass diese um eine Stunde von den früher angekündigten Zeiten verlängert wurden): 6. September 2021 4:00 Uhr UTC – 10:00 Uhr UTC 14. September 2021 14:00 Uhr UTC – 10:00 Uhr UTC

Azure Repos

Neue TFVC-Seiten allgemein verfügbar

Wir haben verschiedene Seiten in Azure DevOps aktualisiert, um eine neue Webplattform zu verwenden, um die Erfahrung konsistenter und barrierefreier für die verschiedenen Dienste zu machen. TFVC-Seiten wurden aktualisiert, um die neue Webplattform zu verwenden, und diese Änderungen wurden seit mehreren Monaten in der Vorschau angezeigt. Mit diesem Update stellen wir die neuen TFVC-Seiten allgemein zur Verfügung. Mit diesem Update wird in den Benutzereinstellungen kein Vorschaufeature namens "Neue TFVC-Seiten" mehr angezeigt.

Konfigurationsmöglichkeit, dass Branchersteller nicht die Berechtigung „Berechtigungen verwalten“ in ihren Branches erhalten

Wenn Sie eine neue Verzweigung erstellen, erhalten Sie "Berechtigungen verwalten" für diese Verzweigung. Mit dieser Berechtigung können Sie die Berechtigungen anderer Benutzer ändern oder zusätzliche Benutzer zulassen, um zu dieser Verzweigung beizutragen. Beispielsweise kann ein Verzweigungsersteller diese Berechtigung verwenden, um einem anderen externen Benutzer das Vornehmen von Änderungen am Code zu ermöglichen. Sie können auch zulassen, dass eine Pipeline (Builddienstidentität) den Code in dieser Verzweigung ändert. In bestimmten Organisationen mit höheren Complianceanforderungen sollten Benutzer diese Änderungen nicht vornehmen können.

Mit diesem Update können Sie alle Repositorys in Ihrem Teamprojekt konfigurieren und verzweigte Ersteller daran hindern, die Berechtigung "Berechtigungen verwalten" zu erhalten. Navigieren Sie hierzu zu den Projekteinstellungen, wählen Sie Repositorys und dann Einstellungen für alle Repositorys oder ein bestimmtes Repository aus.

Alle Repositoryeinstellungen

Diese Einstellung ist standardmäßig aktiviert, um das vorhandene Verhalten nachzuahmen. Sie können es jedoch deaktivieren, wenn Sie dieses neue Sicherheitsfeature verwenden möchten.

Forkbenutzer können nicht mehr für eigene Upstream-PRs abstimmen

Mit Azure Repos können Benutzer mit der Berechtigung "Lesen" in einem Repository das Repository verzweigen und Änderungen an ihrer Verzweigung vornehmen. Um eine Pull-Anforderung mit ihren Änderungen an den Upstream zu übermitteln, benötigen Benutzer die Berechtigung "Mitwirken an Pullanforderungen" für den Upstream. Diese Berechtigung regelt jedoch auch, wer über Pull-Anfragen im upstream-Repository abstimmen kann. Daher können Sie in Situationen auftreten, in denen ein Benutzer, der kein Mitwirkender am Repository ist, eine Pullanforderung übermitteln und dazu führen kann, dass sie zusammengeführt wird, je nachdem, wie Sie die Verzweigungsrichtlinien einrichten.

In Organisationen, die ein Internes Quellmodell fördern, ist fork-and-contribute ein gängiges Muster. Um dieses Muster weiter zu sichern und zu fördern, ändern wir die Berechtigung zur Abstimmung über einen Pull-Antrag von "Mitwirken an Pull-Anfragen" in "Mitwirken". Diese Änderung wird jedoch nicht standardmäßig in allen Organisationen vorgenommen. Sie müssen sich anmelden und eine neue Richtlinie für Ihr Repository auswählen, die als "Strenger Abstimmungsmodus" bezeichnet wird, um diese Berechtigung zu wechseln. Es wird empfohlen, dies zu tun, wenn Sie auf Forks in Azure Repos angewiesen sind.

Repositoryeinstellungen

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 zu diesen Features halten. Verwenden Sie das Hilfemenü, 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,

Aaron Hallberg