Åtgärdat flera begäranden från utvecklarcommunityn

  • Artikel

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

Azure-pipelines

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.

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.

Exempel på senaste incheckningsmeddelande

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å falsevisar pipelinekörningen BuildNumberbara .

Exempel på pipelinekörning med versionsnummer

Exempel på pipelinekörning med senaste incheckningsmeddelande

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.

Gå till Azure DevOps

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.

Ge ett förslag

Du kan också få råd och dina frågor som besvaras av communityn på Stack Overflow.

Tack,

Aaron Hallberg