Förbättringar av instrumentpanelen för kopiering
Vi är glada över att kunna presentera några efterlängtade förbättringar av förhandsversionen av kopieringsinstrumentpanelen. Du kan nu kopiera en instrumentpanel till ett annat team, samma team eller ett annat projekt – och konfigurationen av team och frågor uppdateras på den nya instrumentpanelen. Detta minimerar ytterligare det arbete som krävs för att skapa liknande instrumentpaneler från grunden för flera team.
Mer information finns i följande funktionsbeskrivningar.
Allmänt
Azure-pipelines
- Automatiska återförsök för en aktivitet
- Använda indata från en annan uppgift i en dekoratör
- Förbättringar av användningshistorik för tjänstanslutningar
- Standardagentspecifikationen för klassiska pipelines är nu Windows-2019
Rapportering
Allmänt
Tilldela rollen Azure DevOps-administratör till en Azure AD grupp
Azure DevOps-administratörsrollen, som krävs för att konfigurera Azure AD klientprinciper i Azure DevOps, kan nu tilldelas till en Azure AD grupper. Läs mer om hur du använder Azure AD grupper för att hantera rolltilldelningar i Azure AD.
Azure-pipelines
Automatiska återförsök för en aktivitet
När du har en fläckig uppgift som misslyckas tillfälligt i en pipeline kan du behöva köra pipelinen igen för att den ska lyckas. I de flesta fall är det bästa sättet att hantera en flagnande uppgift eller ett skript genom att åtgärda själva uppgiften eller skriptet. Om din testuppgift till exempel misslyckas i en pipeline på grund av flagnande tester är det alltid en bra idé att åtgärda de flagnande testerna och göra dem mer tillförlitliga. Om skriptet misslyckas då och då är det på samma sätt bättre att åtgärda skriptet, till exempel genom att introducera återförsök i skriptet.
Det finns dock vissa fall där du kanske vill försöka utföra uppgiften igen. Ett vanligt användningsfall för detta är en uppgift som laddar ned ett paket (t.ex. NuGet, npm osv.). Vi har ofta observerat att dessa uppgifter är mottagliga för nätverksfel och tillfälliga fel på paketvärdservrarna. Vi har hört din feedback om att det skulle vara bättre att automatiskt försöka utföra sådana misslyckade uppgifter igen utan att behöva starta om hela pipelinen igen.
Baserat på din feedback har vi lagt till en funktion för att automatiskt försöka utföra en aktivitet i en pipeline igen när den misslyckas. Om du använder YAML-pipelines kan du ange dessa indata på följande sätt:
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
När du använder klassiska bygg- eller versionspipelines kan du ange den här egenskapen under kontrollalternativen för uppgiften.
Här följer några saker att tänka på när du använder återförsök:
- Den misslyckade uppgiften görs om omedelbart.
- Det finns inget antagande om uppgiftens idempotens. Om aktiviteten har sidoeffekter (till exempel om den delvis skapade en extern resurs) kan den misslyckas andra gången den körs.
- Det finns ingen information om antalet återförsök som gjorts tillgängliga för aktiviteten.
- En varning läggs till i aktivitetsloggarna som anger att den har misslyckats innan den görs ett nytt försök.
- Alla försök att försöka utföra en aktivitet igen visas i användargränssnittet som en del av samma aktivitetsnod.
Anteckning
Kräver agentversion 2.194.0 eller senare. Stöds inte för agentlösa uppgifter.
Använda indata från en annan uppgift i en dekoratör
Vi har nyligen lagt till en funktion för att mata in en aktivitet automatiskt i en pipeline före en annan målaktivitet i pipelinen. Vi förbättrar nu den funktionen genom att låta dig anpassa den inmatade aktiviteten med hjälp av målaktivitetens indataparametrar. Syntaxen för att skriva en dekoratör för att göra detta är följande:
{
"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>"]
}
}
],
...
}
Den här funktionen fungerar bara när du använder pre-task-tasks eller post-task-tasks som mål för inmatning och anger targettask avsnittet egenskaper i bidraget. Du kan sedan lägga till ytterligare en egenskap med namnet targettaskinputs och ange en lista över indataparameternamn som godkänts av målaktiviteten. Dessa indata görs nu tillgängliga för den inmatade uppgiften.
Ett vanligt användningsfall som kan åstadkommas med ett sådant scenario är följande. Anta att du vill mata in en uppgift som automatiskt loggar namnet på artefakten som publiceras av en version. Artefaktens namn är en indata för PublishBuildArtifacts uppgiften. Din inmatade uppgift kan nu hämta samma indataparameter och använda den för loggning.
Förbättringar av användningshistorik för tjänstanslutningar
När en pipeline använder en tjänstanslutning loggas den användningen i anslutningens historik. Administratörer av tjänstanslutningen kan granska användningshistoriken genom att gå till projektinställningarna och välja lämplig tjänstanslutning. Det uppstod vissa problem med användningshistoriken för tjänstanslutningar som har åtgärdats med den här uppdateringen. Korrigeringar omfattar följande:
- När en tjänstanslutning används i ett distributionsjobb (i stället för ett vanligt jobb) loggades inte den användningen.
- Om du använde flera tjänstanslutningar i flera steg i en pipeline skulle alla tjänstanslutningar visa en post i deras användningshistorik även om vissa av stegen hoppades över.
Standardagentspecifikationen för klassiska pipelines är nu Windows-2019
I de senaste versionsanteckningarna tillkännagav vi ett utfasningsschema för vs2017-win2016 värdbaserade avbildningar. Som förberedelse för detta ändrar vi nu standardagentspecifikationen när vi skapar nya pipelines i klassiska pipelines till windows-2019.
Rapportering
Kopiera förbättringar av instrumentpanelen
Vi är glada över att kunna presentera den offentliga förhandsversionen av instrumentpanelen för kopiering 2! Frågor och konfiguration överförs nu med kopieringsåtgärden. Tack för ditt tålamod eftersom det tog lite längre tid än förväntat att lösa några av problemen.
Förhandsversionen är aktiverad som standard med funktionsflaggan Kopiera instrumentpanelsupplevelse (under förhandsversionsfunktioner).
Om du vill kopiera en instrumentpanel går du först till den instrumentpanel som du vill kopiera. För det andra klickar du på menyn för att öppna Kopiera instrumentpanel och klickar sedan på den.
Ange sedan namnet och beskrivningen av den nya instrumentpanelen och välj sedan instrumentpanelstyp, Team eller Projekt. När du väljer en teaminstrumentpanel väljs det nya projektet och teamet från respektive listruta. För en projektinstrumentpanel krävs endast projektet.
Du kommer till den nyligen skapade instrumentpanelen när du har klickat på knappen Skapa . Widgetarna och layouten förblir desamma.
I bakgrunden skapas en mapp med namnet på den nya instrumentpanelen i Delade frågor. Alla frågor för den nya instrumentpanelen kopieras till den mappen. Frågenamnen förblir desamma. Widgetar med en teamkonfiguration uppdateras med det nya teamet. Widgetar med en teamkonfiguration som kopieras från en teaminstrumentpanel till en projektinstrumentpanel behåller den ursprungliga konfigurationen.
Filtrera på null-värden i widgeten för burndown-diagram
Nu kan du filtrera på ett null-värde när du använder Fältvillkor i widgeten för bränningsdiagrammet. Det här beteendet överensstämmer nu med en fråga med samma fältvillkor.
Nästa steg
Anteckning
De här funktionerna kommer att lanseras under de kommande två till tre veckorna.
Gå till Azure DevOps och ta en titt.
Så här ger du feedback
Vi vill gärna höra vad du tycker om dessa funktioner. Använd hjälpmenyn för att rapportera ett problem eller ge ett förslag.
Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.
Tack,
Aaron Hallberg
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för