Vylepšení dashboardu pro kopírování

S radostí oznamujeme několik dlouho očekávaných vylepšení náhledu Copy Dashboard. Teď můžete řídicí panel zkopírovat do jiného týmu, stejného týmu nebo jiného projektu – a konfigurace týmu a dotazu se aktualizují na novém řídicím panelu. Tím se dále minimalizuje práce potřebná k vytvoření podobných řídicích panelů od začátku pro více týmů.

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

General

• Přiřazení role správce Azure DevOps ke skupině Azure AD

Azure Pipelines

• Automatické opakování úkolu
• Využijte vstupy z jiného úkolu v dekorátoru
• Vylepšení historie využití připojení služeb
• Výchozí specifikace agenta pro Classic pipelines je teď Windows-2019

Reportování

• Vylepšení Copy Dashboard
• Filtrování hodnot null ve widgetu grafu burndownu

General

Přiřazení role správce Azure DevOps ke skupině Azure AD

Roli správce Azure DevOps, která je nezbytná ke konfiguraci zásad tenanta Azure AD v Azure DevOps, je teď možné přiřadit ke skupinám Azure AD. Přečtěte si další informace o používání skupin Azure AD ke správě přiřazení rolí v Azure AD.

Azure Pipelines

Automatické opakování úkolu

Pokud máte nestabilní úlohu, která občas selže v rámci pipeline, možná budete muset pipeline znovu spustit, aby byla úspěšná. Ve většině případů je nejlepší způsob, jak vyřešit nestabilní úkol nebo skript, opravit samotný úkol nebo skript. Pokud například vaše testovací úloha selže v pipelině kvůli nestabilním testům, je vždy vhodné tyto testy opravit a zajistit jejich spolehlivost. Podobně platí, že pokud skript jednou za chvíli selže, je lepší skript opravit, například zavedením opakování ve skriptu.

Existují však některé případy, kdy můžete chtít úlohu zopakovat. Běžným případem použití je úloha, která stáhne balíček (např. NuGet, npm atd.). Často jsme zjistili, že tyto úlohy jsou náchylné k selháním sítě a k přechodným selháním na hostitelských serverech balíčků. Slyšeli jsme vaši zpětnou vazbu, že by bylo lepší automaticky opakovat takové neúspěšné úlohy, aniž byste museli znovu restartovat celý kanál.

Na základě vaší zpětné vazby jsme přidali funkci, která při selhání automaticky zopakuje úlohu v procesu. Pokud používáte kanály YAML, můžete tento vstup nastavit následujícím způsobem:

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Pokud používáte klasické build nebo release pipeline, můžete tuto vlastnost nastavit pod možnostmi řízení úkolu.

Při použití opakování je potřeba vzít v úvahu několik věcí:

• Neúspěšná úloha se okamžitě opakuje.
• Neexistuje žádný předpoklad o idempotenci úkolu. Pokud má úloha vedlejší účinky (například pokud částečně vytvořila externí prostředek), může selhat při druhém spuštění.
• Pro úkol není k dispozici žádné informace o počtu opakování.
• Do protokolů úloh se přidá upozornění, které značí, že se nezdařilo před opakováním.
• Všechny pokusy o opakování úkolu se zobrazí v uživatelském rozhraní jako součást stejného uzlu úkolu.

Poznámka:

Vyžaduje agenta verze 2.194.0 nebo novější. Úlohy bez agentů nejsou podporovány.

Spotřebovat vstupy z jiného úkolu v dekorátoru

Nedávno jsme přidali funkci pro automatické vložení úlohy do kanálu před jinou cílovou úlohu v daném kanálu. Tuto funkci teď vylepšujeme tím, že vám umožní přizpůsobit vloženou úlohu pomocí vstupních parametrů cílové úlohy. Syntaxe pro zápis dekorátoru, který to provede, je následující:

{
    "contributions": [
        {
            "id": <my-required-task>,
            "type": "ms.azure-pipelines.pipeline-decorator",
            "targets": [
                "ms.azure-pipelines-agent-job.pre-task-tasks",
                "ms.azure-pipelines-agent-job.post-task-tasks"
            ],
            "properties": {
                "template": "my-decorator.yml",
                "targettask": <target-task-id>,
                "targettaskinputs": ["<name of input>"]
            }
        }
    ],
    ...
}

Tato funkce funguje pouze v případě, že použijete pre-task-tasks nebo post-task-tasks jako cíl injektáže a zadáte targettask v části vlastností příspěvku. Potom můžete přidat další volanou targettaskinputs vlastnost a zadat seznam názvů vstupních parametrů přijatých cílovou úlohou. Tyto vstupy jsou nyní zpřístupněny injektovanému úkolu.

Běžný případ použití, kterého lze dosáhnout pomocí takového scénáře, je následující. Řekněme, že chcete přidat úlohu, která automaticky zapisuje název artefaktu publikovaného sestavením. Název artefaktu je vstupem úkolu PublishBuildArtifacts . Vložený úkol teď může získat stejný vstupní parametr a použít ho k protokolování.

Vylepšení historie používání připojení ke službám

Pokud kanál používá připojení ke službě, zaprotokoluje se toto využití v historii připojení. Správci připojení služby můžou zkontrolovat historii využití tak, že přejdou do nastavení projektu a vyberou příslušné připojení služby. Došlo k problémům s historií používání připojení služeb, která byla opravena touto aktualizací. Mezi opravy patří:

• Při použití připojení služby v úloze nasazení (místo běžné úlohy) nebylo využití připojení služby zaznamenáno.
• Pokud jste použili více připojení ke službě v několika fázích pipeline, všechna připojení ke službě by měla záznam ve své historii využití, i když některé fáze byly vynechány.

Výchozí specifikace agenta pro klasické kanály je teď Windows-2019

V posledních poznámkách k vydání jsme oznámili harmonogram ukončení podpory pro vs2017-win2016 hostované image. V rámci přípravy na to teď měníme výchozí specifikaci agenta při vytváření nových kanálů v klasických kanálech na windows-2019.

Reportování

Vylepšení panelu Nástěnka pro kopírování

S radostí oznamujeme veřejnou ukázku fáze 2 panelu pro kopírování! Dotazy a konfigurace se teď přenesou pomocí operace kopírování. Děkujeme za vaši trpělivost, trvalo to trochu déle, než se očekávalo, vyřešit některé problémy.

Náhled je ve výchozím nastavení zapnutý s vlajkou funkce Kopírovat prostředí řídicího panelu (v části náhledových funkcí).

Pokud chcete řídicí panel zkopírovat, nejprve přejděte na řídicí panel, který chcete zkopírovat. Za druhé kliknutím na nabídku otevřete Kopírovat přehled a potom na něj klikněte.

Dále zadejte název a popis nového řídicího panelu a pak vyberte typ řídicího panelu, tým nebo projekt. Při výběru týmového řídicího panelu se nový projekt a tým vyberou z příslušných rozevíracích polí. U řídicího panelu Projektu se vyžaduje jenom projekt.

Po kliknutí na tlačítko Vytvořit přejdete na nově vytvořený řídicí panel. Widgety a rozložení zůstanou stejné.

Na pozadí se ve sdílených dotazech vytvoří složka s názvem nového řídicího panelu. Všechny dotazy na nový řídicí panel se zkopírují do této složky. Názvy dotazů zůstávají stejné. Widgety s konfigurací týmu se aktualizují s novým týmem. Widgety s konfigurací týmu, která se kopíruje z řídicího panelu týmu do řídicího panelu projektu, si zachovají původní konfiguraci.

Filtrování nulových hodnot ve widgetu burndown grafu

Při použití kritérií polí ve widgetu grafu burndownu teď můžete filtrovat hodnotu null. Toto chování je teď konzistentní s dotazem, který používá stejná kritéria polí.

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 stránku Azure DevOps a podívejte se.

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ík

Aaron Hallberg