Azure Pipelines – Sprint 192 Aktualisierung

Features

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 erhalten, in dem darum gebeten wird, 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

Ermöglichen Sie Mitwirkenden, die Suche nach PR-Kommentaren vor der Build-Validierung zu überspringen.

Wenn Sie Azure Pipelines mit GitHub-Repositories verwenden, empfehlen wir, keine PR-Validierungspipeline für Beiträge auszuführen, die aus einem geforkten Repository stammen. Die bewährte Methode besteht darin, dass zuerst einer der Mitwirkenden des Repositorys die Änderung überprüft und dann einen Kommentar zur PR hinzufügt, der die Pipeline auslöst. 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 überprüfen zu lassen, können Sie diese Richtlinie auch nur auf Beiträge anwenden, die von Nicht-Teammitgliedern stammen.

Mit diesem Update ermöglichen wir Ihnen, das Einholen von PR-Kommentaren bei Beiträgen, die von einem beliebigen Mitwirkenden stammen, zu überspringen. 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 windows-2022 als Bild in Ihrer Pipeline referenzieren.

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 Ankündigungsproblem und im Dokumentations-Repository für virtuelle Umgebungen finden.

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 macos-11 als Bild in Ihrer Pipeline verweisen.

pool:
  vmImage: macos-11

Entfernen des Ubuntu 16.04-Images auf 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 auf Ubuntu-18.04 oder die auf Ubuntu 20.04 LTS ausgeführte Version ubuntu-latest migrieren.

Builds, die Ubuntu-16.04 verwenden, haben bereits eine Warnung, die in ihnen protokolliert wird. 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

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.

Navigieren Sie zu Azure DevOps.

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.

  • Zuletzt aktualisiert um