Vylepšení kopírování řídicího panelu

S radostí oznamujeme některá dlouho očekávaná vylepšení náhledu řídicího panelu kopírování. Řídicí panel teď můžete zkopírovat do jiného týmu, stejného týmu nebo jiného projektu – a konfigurace týmu a dotazu se aktualizuje 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í.

Obecné

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

Azure Pipelines

• Automatické opakování úkolu
• Využití vstupů z jiného úkolu ve dekorátoru
• Vylepšení historie využití připojení služeb
• Výchozí specifikace agenta pro klasické kanály je teď Windows-2019.

Generování sestav

• Vylepšení kopírování řídicího panelu
• Filtrování hodnot null ve widgetu burndown chart

Obecné

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

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

Azure Pipelines

Automatické opakování úkolu

Pokud máte v kanálu občasnou úlohu, která selhává, možná budete muset kanál spustit znovu, aby byl úspěšný. Ve většině případů je nejlepším způsobem, jak řešit problémový úkol nebo skript, opravit samotný úkol nebo skript. Pokud například vaše testovací úloha selže v kanálu kvůli nešiřlivým testům, je vždy vhodné opravit foukané testy a zajistit jejich spolehlivost. Podobně platí, že pokud váš skript jednou za čas selže, je lepší skript opravit, například zavedením opakovaných pokusů v rámci skriptu.

V některých případech ale 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 zaznamenali, že tyto úlohy jsou náchylné k selháním sítě a přechodným selháním na serverech hostujících balíček. Vyslyšeli jsme vaši zpětnou vazbu, že by bylo lepší tyto neúspěšné úlohy automaticky opakovat, aniž byste museli znovu restartovat celý kanál.

Na základě vaší zpětné vazby jsme přidali funkci, která automaticky opakuje úlohu v kanálu, když selže. 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 kanály klasického sestavení nebo verze, můžete tuto vlastnost nastavit pod možnostmi ovládacího prvku pro úlohu.

Tady je několik věcí, které byste si při opakovaném použití poznamenali:

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

Poznámka

Vyžaduje agenta verze 2.194.0 nebo novější. Nepodporuje se pro úlohy bez agentů.

Využití vstupů z jiného úkolu ve dekorátoru

Nedávno jsme přidali funkci , která automaticky vloží úlohu 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íme přizpůsobit vložený úkol pomocí vstupních parametrů cílové úlohy. Syntaxe pro zápis dekorátoru 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 pro injektáž a zadáte targettask v části vlastností příspěvku. Pak můžete přidat další vlastnost s názvem targettaskinputs a zadat seznam názvů vstupních parametrů přijatých cílovým úkolem. Tyto vstupy jsou nyní zpřístupněny vložené úloze.

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

Vylepšení historie využití připojení služeb

Pokud kanál používá připojení služby, toto využití se zaznamená do historie připojení. Správci připojení služby můžou historii využití zkontrolovat tak, že přejdou do nastavení projektu a vyberou příslušné připojení služby. V této aktualizaci byly opraveny některé problémy s historií využití připojení služeb. Mezi opravy patří:

• Při použití připojení služby v úloze nasazení (místo běžné úlohy) se toto využití neprotokoluje.
• Pokud jste použili více připojení služeb v několika fázích kanálu, všechna připojení služby by v historii využití zobrazovala záznam, i když se některé fáze přeskočily.

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

V poslední zprávě k verzi jsme oznámili plán vyřazení hostovaných vs2017-win2016 imagí. 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.

Generování sestav

Vylepšení kopírování řídicího panelu

S radostí oznamujeme fázi 2 verze Public Preview kopírování řídicího panelu! Dotazy a konfigurace se teď přenášejí pomocí operace kopírování. Děkujeme za vaši trpělivost, protože vyřešení některých problémů trvalo trochu déle, než se čekalo.

Náhled je ve výchozím nastavení zapnutý s příznakem funkce Kopírovat prostředí řídicího panelu (v části Funkce preview).

Pokud chcete řídicí panel zkopírovat, přejděte nejdřív na řídicí panel, který chcete zkopírovat. Potom kliknutím na nabídku zobrazíte Příkaz Kopírovat řídicí panel a potom na ni 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 řídicího panelu týmu se v příslušných rozevíracích polích vybere nový projekt a tým. U řídicího panelu Projectu se vyžaduje jenom projekt.

Po kliknutí na tlačítko Vytvořit se dostanete na nově vytvořený řídicí panel. Widgety a rozložení zůstávají 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 týmového řídicího panelu do řídicího panelu projektu, si zachovají původní konfiguraci.

Filtrování hodnot null ve widgetu burndown chart

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

Další kroky

Poznámka

Tyto funkce 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.

Přejít 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 odpovědi na vaše otázky od komunity na Webu Stack Overflow.

Díky,

Aaron Hallberg