Åtgärdat flera begäranden från utvecklarcommunityn
Som svar på din feedback har vi prioriterat flera funktioner som du har begärt i utvecklarcommunityn. I Pipelines har vi lagt till stöd för funktionen för strängdelning i YAML-uttryck. Dessutom låter vi dig nu inaktivera visning av det senaste incheckningsmeddelandet för en pipelinekörning. I Leveransplaner ökade vi teamgränsen från 15 till 20.
Mer information finns i viktig information.
Azure-tavlor
- Öka teamgränsen för leveransplaner från 15 till 20
- Bugg i Hämta API för rapportering av arbetsobjektlänkar har åtgärdats
- Nya felkorrigeringar för Boards Hub
Azure-pipelines
- Inaktivera visning av det senaste incheckningsmeddelandet för en pipelinekörning
- Förbrukade resurser och mallparametrar i Rest API för pipelineskörningar
- Lägg till stöd för funktionen för strängdelning i YAML-malluttryck
- Synkronisera inte taggar när du hämtar en Git-lagringsplats
- Uppdaterat brownout-schema för Ubuntu 18.04-bilder
Azure-tavlor
Öka teamgränsen för leveransplaner från 15 till 20
Med leveransplaner kan du visa flera kvarvarande uppgifter och flera team i organisationen. Tidigare kunde du visa 15 kvarvarande teamloggar, inklusive en blandning av kvarvarande uppgifter och team från olika projekt. I den här sprinten ökade vi maxgränsen från 15 till 20.
Bugg i Hämta API för rapportering av arbetsobjektlänkar har åtgärdats
Vi har åtgärdat en bugg i Hämta API för rapportarbetsobjektlänkar för att returnera rätt remoteUrl-värde för System.LinkTypes.Remote.Related
länktyper. Innan den här korrigeringen returnerade vi fel organisationsnamn och ett projekt-ID som saknas.
Nya felkorrigeringar för Boards Hub
I den här sprinten har vi åtgärdat flera buggar för New Boards Hub. Du kan se en lista över felkorrigeringar i blogginlägget New Boards Hub, Sprint 209 update.
Azure-pipelines
Inaktivera visning av det senaste incheckningsmeddelandet för en pipelinekörning
Tidigare användes pipelines-användargränssnittet för att visa det senaste incheckningsmeddelandet när en pipeline kördes.
Det här meddelandet kan till exempel vara förvirrande när din YAML-pipelines kod finns på en annan lagringsplats än den som innehåller koden den skapar. Vi har hört din feedback från Utvecklarcommunityn som ber oss om ett sätt att aktivera/inaktivera att lägga till det senaste incheckningsmeddelandet i rubriken för varje pipelinekörning.
Med den här uppdateringen har vi lagt till en ny YAML-egenskap med namnet appendCommitMessageToRunName
, som gör att du kan göra exakt det. Som standard är egenskapen inställd på true
. När du ställer in den på false
visar pipelinekörningen BuildNumber
bara .
Förbrukade resurser och mallparametrar i Rest API för pipelineskörningar
Rest-API:et extended Pipelines Runs returnerar nu fler typer av artefakter som används av en pipelinekörning och de parametrar som används för att utlösa körningen. Vi har förbättrat API:et container
för att returnera resurserna och pipeline
och mallparametrarna som används i en pipelinekörning. Nu kan du till exempel skriva efterlevnadskontroller som utvärderar lagringsplatser, containrar och andra pipelinekörningar som används av en pipeline.
Här är ett exempel på den nya svarstexten.
"resources":
{
"repositories":
{
"self":
{
"repository":
{
"id": "e5c55144-277b-49e3-9905-2dc162e3f663",
"type": "azureReposGit"
},
"refName": "refs/heads/main",
"version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
},
"MyFirstProject":
{
"repository":
{
"id": "e5c55144-277b-49e3-9905-2dc162e3f663",
"type": "azureReposGit"
},
"refName": "refs/heads/main",
"version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
}
},
"pipelines":
{
"SourcePipelineResource":
{
"pipeline":
{
"url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
"id": 51,
"revision": 3,
"name": "SourcePipeline",
"folder": "\\source"
},
"version": "20220801.1"
}
},
"containers":
{
"windowscontainer":
{
"container":
{
"environment":
{
"Test": "test"
},
"mapDockerSocket": false,
"image": "mcr.microsoft.com/windows/servercore:ltsc2019",
"options": "-e 'another_test=tst'",
"volumes":
[
"C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
],
"ports":
[
"8080:80",
"6379"
]
}
}
}
},
"templateParameters":
{
"includeTemplateSteps": "True"
}
Lägg till stöd för funktionen för strängdelning i YAML-malluttryck
YAML-pipelines ger dig praktiska sätt att minska koddupliceringen, till exempel att loopa igenom värdet för each
en lista eller egenskapen för ett objekt.
Ibland representeras uppsättningen objekt som ska itereras genom som en sträng. När till exempel listan över miljöer som ska distribueras till definieras av strängen integration1, integration2
.
När vi lyssnade på din feedback från Utvecklarcommunityn hörde vi att du ville ha en strängfunktion split
i YAML-malluttryck.
Nu kan split
du en sträng och iterera över each
dess delsträngar.
variables:
environments: integration1, integration2
jobs:
- job: Deploy
steps:
- ${{ each env in split(variables.environments, ', ') }}:
- script: ./deploy.sh -e ${{ env }}
- script: ./runTest.sh -e ${{ env }}
Synkronisera inte taggar när du hämtar en Git-lagringsplats
Utcheckningsaktiviteten använder --tags
alternativet för att hämta innehållet i en Git-lagringsplats. Detta gör att servern hämtar alla taggar samt alla objekt som pekas på av dessa taggar. Detta ökar tiden för att köra aktiviteten i en pipeline – särskilt om du har en stor lagringsplats med ett antal taggar. Dessutom synkroniserar utcheckningsuppgiften taggar även när du aktiverar alternativet för ytlig hämtning, vilket kan motverka dess syfte. För att minska mängden data som hämtas eller hämtas från en Git-lagringsplats har vi nu lagt till ett nytt alternativ för uppgiften för att styra beteendet för synkronisering av taggar. Det här alternativet är tillgängligt både i klassiska pipelines och YAML-pipelines.
Det här beteendet kan antingen styras från YAML-filen eller från användargränssnittet.
Om du vill avregistrera dig från att synkronisera taggarna via YAML-filen lägger du till fetchTags: false
i utcheckningssteget. När alternativet fetchTags
inte anges är det samma som om fetchTags: true
det används.
steps:
- checkout: self # self represents the repo where the initial Pipelines YAML file was found
clean: boolean # whether to fetch clean each time
fetchTags: boolean # whether to sync the tags
fetchDepth: number # the depth of commits to ask Git to fetch
lfs: boolean # whether to download Git-LFS files
submodules: boolean | recursive # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
path: string # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
persistCredentials: boolean # set to 'true' to leave the OAuth token in the Git config after the initial fetch
Om du vill ändra beteendet för befintliga YAML-pipelines kan det vara enklare att ange det här alternativet i användargränssnittet i stället för att uppdatera YAML-filen. Om du vill navigera till användargränssnittet öppnar du YAML-redigeraren för pipelinen, väljer Utlösare och sedan Process och sedan utcheckningssteget.
Om du anger den här inställningen både i YAML-filen och i användargränssnittet har värdet som anges i YAML-filen företräde.
För alla nya pipelines som du skapar (YAML eller klassisk) synkroniseras taggarna fortfarande som standard. Det här alternativet ändrar inte beteendet för befintliga pipelines. Taggarna synkroniseras fortfarande i dessa pipelines om du inte uttryckligen ändrar alternativet enligt beskrivningen ovan.
Uppdaterat brownout-schema för Ubuntu 18.04-bilder
Azure Pipelines inaktuella Ubuntu 18.04-avbildningen (ubuntu-18.04
) i våra värdbaserade pooler. Den här avbildningen dras tillbaka den 1 december. Du kan börja se längre kötider.
För att hjälpa dig att bättre identifiera vilka pipelines som använder ubuntu-18.04-avbildningen planerar vi brownouts. Jobb kommer att misslyckas under en brownout-period.
- Varningsmeddelanden visas vid pipelinekörningar med hjälp av ubuntu-18.04-bilden
- Det finns ett skript som hjälper dig att hitta pipelines med inaktuella avbildningar, inklusive ubuntu-18.04
- Vi schemalägger korta "brownouts". Alla ubuntu-18.04-körningar misslyckas under brownout-perioden. Därför rekommenderar vi att du migrerar dina pipelines före brownouts.
Brownout-schema (uppdaterat)
- 3 oktober, 12:00 UTC - 3 oktober, 14:00 UTC
- 18 oktober, 14:00 UTC - 18 oktober, 16:00 UTC
- 15 november, 18:00 UTC - 15 november, 20:00 UTC
- 30 november, 20:00 UTC - 30 november, 22:00 UTC
- 15 december, 20:00 UTC - 16 december 00:00 UTC
- 5 januari 10.00 UTC - 5 januari 14.00 UTC
- 13 januari 12.00 UTC - 13 januari 16.00 UTC
- 18 januari 14.00 UTC - 18 januari 18.00 UTC
- 24 januari 16.00 UTC - 24 januari 20.00 UTC
- 1 februari 18.00 UTC - 1 februari 22.00 UTC
- 7 februari 16.00 UTC - 7 februari 22.00 UTC
- 13 februari, 14.00 UTC - 13 februari, 22.00 UTC
- 21 februari, 10.00 UTC - 21 februari, 22.00 UTC
- 28 februari, 10.00 UTC - 28 februari, 22.00 UTC
- 6 mars 00.00 UTC - 7 mars 00.00 UTC
- 13 mars, 00.00 UTC - 14 mars, 00.00 UTC
- 21 mars 00,00 UTC - 22 mars 00,00 UTC
Nästa steg
Anteckning
Dessa funktioner kommer att distribueras 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 de här funktionerna. 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