Podpora zástupných znaků a podmíněných výrazů v souborech kanálů YAML

V tomto sprintu jsme zahrnuli podporu zástupných znaků a podmíněných výrazů pro soubory kanálů YAML. Kromě toho jsme provedli několik aktualizací hostovaných imagí Azure Pipelines.

Podrobnosti najdete v následujících popisech funkcí.

Azure Pipelines

• Nové podmíněné výrazy YAML
• Podpora zástupných znaků ve filtrech cest
• Podpora více stavů v Bitbucketu
• Možnost přeskočit vyhledávání komentářů PR před ověřením sestavení pro přispěvatele
• Dostupnost Windows Serveru 2022 se sadou Visual Studo 2022 v agentech hostovaných Microsoftem (Preview)
• Obecná dostupnost macOS 11 Big Sur na agentech hostovaných Microsoftem
• Odebrání image Ubuntu 16.04 na agentech hostovaných Microsoftem

Azure Repos

• Obecná dostupnost nových stránek TFVC
• Možnost nakonfigurovat tvůrce větví tak, aby nedostávali oprávnění pro správu svých větví
• Možnost zabránit uživatelům forků v hlasování o upstreamových žádostech o přijetí změn

Azure Pipelines

Nové podmíněné výrazy YAML

Psaní podmíněných výrazů v souborech YAML je teď jednodušší s použitím ${{ else }} výrazů a ${{ elseif }} výrazů. Níže jsou uvedeny příklady použití těchto výrazů v souborech kanálů YAML.

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

Podpora zástupných znaků ve filtrech cest

Zástupné znaky lze použít při zadávání větví zahrnutí a vyloučení pro triggery CI nebo PR v souboru YAML kanálu. Nemůžete je ale použít při zadávání filtrů cest. Nemůžete například zahrnout všechny cesty, které odpovídají src/app/**/myapp*. Na to upozornilo několik zákazníků jako nepříjemnosti. Tato aktualizace tuto mezeru vyplní. Při zadávání filtrů cest teď můžete použít zástupné znaky (**, *nebo ?).

Podpora více stavů v Bitbucketu

Azure Pipelines se integruje s úložišti Bitbucket a podporuje triggery CI a PR. Z jednoho úložiště Bitbucket můžete nastavit několik kanálů. Po dokončení těchto kanálů se ale v Bitbucketu zobrazil pouze jeden stav. Slyšeli jsme zpětnou vazbu od komunity vývojářů s žádostí o zobrazení stavu jednotlivých kanálů samostatně v Bitbucketu. V této aktualizaci jsme aktualizovali volání rozhraní API na Bitbucket a předali další informace o názvu kanálu.

Možnost přeskočit vyhledávání komentářů PR před ověřením sestavení pro přispěvatele

Pokud používáte Azure Pipelines s úložišti GitHub, doporučujeme automaticky nespouštět kanál ověření žádosti o přijetí změn pro příspěvky přijaté z forku úložiště. Osvědčeným postupem je nejprve zkontrolovat změnu jeden z spolupracovníků úložiště a pak přidat komentář k žádosti o přijetí změn, aby se kanál aktivoval. Tato nastavení můžete nakonfigurovat tak, že ve webovém editoru kanálu vyberete nabídku Triggers (pro kanály YAML) nebo kartu Triggers (pro klasické kanály buildu). Místo toho, abyste museli nejprve zkontrolovat všechny žádosti o přijetí změn ze forku od člena týmu, můžete tuto zásadu vynutit jenom u příspěvků, které pocházejí od členů jiného týmu.

Díky této aktualizaci vám umožňuje přeskočit hledání komentáře k žádosti o přijetí změn od příspěvků přijatých jakýmkoli přispěvatelem. Když vytvoříte fork a vytvoříte žádost o přijetí změn do upstreamu, nepovažujete se za přispěvatele upstreamového úložiště, dokud se vaše žádost o přijetí změn nesloučí. Po sloučení žádosti o přijetí změn budete považováni za přispěvatele. Když vyberete novou možnost uvedenou níže, bude muset někdo z vašeho týmu poprvé odeslat žádost o přijetí změn z forku a přidat komentář k aktivaci kanálu. Jakmile se ale žádost o přijetí změn sloučí, všechny další příspěvky, které provedl jiný člen než tým, kanál přímo aktivuje, aniž by čekal na komentář k žádosti o přijetí změn.

Dostupnost Windows Serveru 2022 se sadou Visual Studo 2022 v agentech hostovaných Microsoftem (Preview)

Windows Server 2022 a Visual Studio Enterprise 2022 Preview jsou teď k dispozici ve verzi Preview na agentech hostovaných Microsoftem. Můžete ho použít tak, že na něj v kanálu odkazujete jako na windows-2022 obrázek.

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'

Když ve svých kanálech YAML odkazujete na nejnovější fond windows, bude to stále znamenat windows-2019, nikoli windows-2022, zatímco druhý fond je ve verzi Preview.

Image kanálu Windows Serveru 2022 má v porovnání s Windows Serverem 2019 různé nástroje a verze nástrojů. Podrobnosti najdete v problému s oznámením softwaru a v úložišti virtuálních prostředí dokumentace.

Obecná dostupnost macOS 11 na agentech hostovaných Microsoftem

MacOS 11 je teď obecně dostupný na agentech hostovaných Microsoftem. Můžete ho použít tak, že na něj v kanálu odkazujete jako na macos-11 obrázek.

pool:
  vmImage: macos-11

Image kanálu macOS 11 obsahuje různé nástroje a nástroje, kde najdete další informace o této verzi, kde najdete úplnou dokumentaci.

Odebrání image Ubuntu 16.04 na agentech hostovaných Microsoftem

Jak jsme oznámili dříve, odebereme image Ubuntu 16.04 z agentů hostovaných Microsoftem 20. září 2021. Tradiční podpora Ubuntu 16.04 od Canonical skončila v dubnu 2021. Budete muset migrovat kanály ubuntu-16.04 na ubuntu-18.04 nebo ubuntu-latest, které budou běžet na Ubuntu 20.04 LTS.

Buildy, které používají Ubuntu-16.04, už mají upozornění, že jsou přihlášené. Abychom měli jistotu, že o této změně vědí všichni, naplánovali jsme 2 krátké "brownouty". Buildy Ubuntu 16.04 se během období brownoutu nezdaří. Proto doporučujeme migrovat pracovní postupy před 6. zářím 2021.

Brownouty jsou naplánované na následující data a časy (všimněte si, že tyto hodnoty byly prodlouženy o hodinu od dřívějších oznámených časů): 6. září 2021 4:00 UTC – 10:00 UTC 14. září 2021 14:00 UTC – 10:00 UTC

Azure Repos

Obecná dostupnost nových stránek TFVC

Aktualizovali jsme různé stránky v Azure DevOps tak, aby používaly novou webovou platformu s cílem zajistit konzistentnější a přístupnější prostředí napříč různými službami. Stránky TFVC byly aktualizovány tak, aby používaly novou webovou platformu, a tyto změny byly už několik měsíců ve verzi Preview. V této aktualizaci zpřístupňujeme nové stránky TFVC obecně. V této aktualizaci se už v uživatelských nastaveních nezobrazí funkce Preview s názvem "Nové stránky TFVC".

Možnost nakonfigurovat tvůrce větví tak, aby nedostávali oprávnění pro správu svých větví

Když vytvoříte novou větev, získáte u této větve oprávnění Spravovat. Toto oprávnění umožňuje změnit oprávnění jiných uživatelů nebo povolit dalším uživatelům přispívat do této větve. Tvůrce větve může například toto oprávnění použít k tomu, aby jiný externí uživatel mohl provádět změny kódu. Nebo můžou kanálu (identitě služby sestavení) povolit změnu kódu v této větvi. V některých organizacích s vyššími požadavky na dodržování předpisů by uživatelé neměli tyto změny provádět.

V této aktualizaci můžete nakonfigurovat všechna úložiště ve vašem týmovém projektu a omezit tvůrce větví, aby získali oprávnění Spravovat oprávnění. Uděláte to tak, že přejdete do nastavení projektu, vyberete Úložiště a pak Nastavení pro všechna úložiště nebo konkrétní úložiště.

Toto nastavení je ve výchozím nastavení zapnuté a napodobuje stávající chování. Pokud ale chcete tuto novou funkci zabezpečení používat, můžete ji vypnout.

Možnost zabránit uživatelům forků v hlasování o upstreamových žádostech o přijetí změn

S Azure Repos můžou uživatelé s oprávněním ke čtení v úložišti vytvořit fork úložiště a provádět změny ve svém forku. Aby uživatelé mohli odeslat žádost o přijetí změn se změnami upstreamu, musí k upstreamu přispívat k žádostem o přijetí změn. Toto oprávnění ale také řídí, kdo může hlasovat o žádostech o přijetí změn v upstreamovém úložišti. V důsledku toho můžete skončit v situacích, kdy uživatel, který není přispěvatelem úložiště, může odeslat žádost o přijetí změn a způsobit jejich sloučení v závislosti na tom, jak nastavíte zásady větve.

V organizacích, které propagují model vnitřního zdroje, je běžný vzor forku a přispívání. Abychom tento model dále zabezpečili a podpořili, měníme oprávnění hlasovat pro žádost o přijetí změn z příspěvku na žádosti o přijetí změn na příspěvek. Tato změna se ale ve výchozím nastavení neprovází ve všech organizacích. Pokud chcete toto oprávnění přepnout, musíte se přihlásit a vybrat v úložišti novou zásadu s názvem Režim striktního hlasování. Doporučujeme, abyste to udělali, pokud se spoléháte na forky v Azure Repos.

Další kroky

Poznámka:

Tyto funkce se budou zavádět během následujících dvou až tří týdnů.

Přejděte na Azure DevOps a podívejte se na ně.

Přechod na Azure DevOps

Jak poskytnout zpětnou vazbu

Rádi bychom slyšeli, co si o těchto funkcích myslíte. Pomocí nabídky nápovědy můžete nahlásit problém nebo poskytnout návrh.

Můžete také získat rady a své otázky zodpovězené komunitou ve službě Stack Overflow.

Díky,

Aaron Hallberg