Meerdere aanvragen van de ontwikkelaarscommunity afgehandeld

  • Artikel

In reactie op uw feedback hebben we prioriteit gegeven aan meerdere functies die u hebt aangevraagd in de ontwikkelaarscommunity. In Pijplijnen hebben we ondersteuning toegevoegd voor de functie voor het splitsen van tekenreeksen in YAML-expressie. Daarnaast kunt u nu het weergeven van het laatste doorvoerbericht voor een pijplijnuitvoering uitschakelen. In Leveringsplannen hebben we de teamlimiet verhoogd van 15 naar 20.

Bekijk de releaseopmerkingen voor meer informatie.

Azure Boards

Azure Pipelines

Azure Boards

De teamlimiet voor leveringsplannen verhogen van 15 naar 20

Met Leveringsplannen kunt u meerdere achterstanden en meerdere teams in uw organisatie bekijken. Voorheen kon u 15 teamachterstanden bekijken, waaronder een combinatie van achterstanden en teams van verschillende projecten. In deze sprint hebben we de maximumlimiet verhoogd van 15 naar 20.

We hebben een fout opgelost in de API Voor het ophalen van rapportwerkitems om de juiste remoteUrl-waarde voor System.LinkTypes.Remote.Related koppelingstypen te retourneren. Vóór deze oplossing hebben we de verkeerde organisatienaam en een ontbrekende project-id geretourneerd.

Oplossingen voor nieuwe Boards Hub-fouten

In deze sprint hebben we meerdere fouten voor New Boards Hub opgelost. U kunt een lijst met oplossingen voor fouten bekijken in het blogbericht New Boards Hub, Sprint 209 update.

Azure Pipelines

Het weergeven van het laatste doorvoerbericht voor een pijplijnuitvoering uitschakelen

Voorheen werd in de gebruikersinterface van Pijplijnen het laatste doorvoerbericht weergegeven bij het weergeven van de uitvoering van een pijplijn.

Voorbeeld van laatste doorvoerbericht

Dit bericht kan verwarrend zijn, bijvoorbeeld wanneer de code van uw YAML-pijplijn zich in een andere opslagplaats bevindt dan de opslagplaats die de code bevat die wordt gebouwd. We hebben uw feedback van de ontwikkelaarscommunity gehoord waarin ons wordt gevraagd om een manier om het meest recente doorvoerbericht toe te voegen aan de titel van elke pijplijnuitvoering in of uit te schakelen.

Met deze update hebben we een nieuwe YAML-eigenschap toegevoegd, met de naam appendCommitMessageToRunName, waarmee u precies dat kunt doen. De eigenschap is standaard ingesteld op true. Wanneer u deze instelt op false, wordt tijdens de pijplijnuitvoering alleen de BuildNumberweergegeven.

Voorbeeld van pijplijnuitvoering met buildnummer

Voorbeeld van pijplijnuitvoering met laatste doorvoerbericht

Verbruikte resources en sjabloonparameters in rest API voor pijplijnenuitvoeringen

De uitgebreide REST API pijplijnen wordt uitgevoerd nu meer typen artefacten geretourneerd die worden gebruikt door een pijplijnuitvoering en de parameters die worden gebruikt om die uitvoering te activeren. We hebben de API verbeterd om de container resources en pipeline en de sjabloonparameters te retourneren die worden gebruikt in een pijplijnuitvoering. U kunt nu bijvoorbeeld nalevingscontroles schrijven die de opslagplaatsen, containers en andere pijplijnuitvoeringen evalueren die door een pijplijn worden gebruikt.

Hier volgt een voorbeeld van de nieuwe antwoordtekst.

"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"
}

Ondersteuning toegevoegd voor de functie voor het splitsen van tekenreeksen in YAML-sjabloonexpressies

YAML-pijplijnen bieden handige manieren om codeduplicatie te verminderen, zoals het doorlopen van een lus door each de waarde van een lijst of eigenschap van een object.

Soms wordt de reeks items die moeten worden herhaald, weergegeven als een tekenreeks. Bijvoorbeeld wanneer de lijst met omgevingen waarin moet worden geïmplementeerd, wordt gedefinieerd door de tekenreeks integration1, integration2.

Terwijl we naar uw feedback van de ontwikkelaarscommunity hebben geluisterd, hoorden we dat u een tekenreeksfunctie split wilde in YAML-sjabloonexpressies.

U kunt split nu een tekenreeks maken en each de subtekenreeksen herhalen.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Tags niet synchroniseren bij het ophalen van een Git-opslagplaats

De uitchecktaak maakt gebruik van --tags de optie voor het ophalen van de inhoud van een Git-opslagplaats. Dit zorgt ervoor dat de server alle tags en alle objecten ophaalt waarnaar door deze tags wordt verwezen. Hierdoor neemt de tijd toe om de taak in een pijplijn uit te voeren, met name als u een grote opslagplaats met een aantal tags hebt. Bovendien synchroniseert de uitchecktaak tags, zelfs wanneer u de optie ondiep ophalen inschakelt, waardoor het doel mogelijk wordt genegeerd. Om de hoeveelheid gegevens te verminderen die worden opgehaald of opgehaald uit een Git-opslagplaats, hebben we nu een nieuwe optie toegevoegd aan de taak om het gedrag van het synchroniseren van tags te beheren. Deze optie is beschikbaar in zowel klassieke als YAML-pijplijnen.

Dit gedrag kan worden beheerd vanuit het YAML-bestand of vanuit de gebruikersinterface.

Als u zich wilt afmelden voor het synchroniseren van de tags via het YAML-bestand, voegt u de fetchTags: false toe aan de stap voor afrekenen. Wanneer de fetchTags optie niet is opgegeven, is deze hetzelfde als als wordt fetchTags: true gebruikt.

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

Als u het gedrag van bestaande YAML-pijplijnen wilt wijzigen, is het wellicht handiger om deze optie in te stellen in de gebruikersinterface in plaats van het YAML-bestand bij te werken. Als u naar de gebruikersinterface wilt navigeren, opent u de YAML-editor voor de pijplijn, selecteert u Triggers, vervolgens Proces en vervolgens de stap Afrekenen.

Als u deze instelling zowel in het YAML-bestand als in de gebruikersinterface opgeeft, heeft de waarde die is opgegeven in het YAML-bestand voorrang.

Voor alle nieuwe pijplijnen die u maakt (YAML of Klassiek), worden tags nog steeds standaard gesynchroniseerd. Met deze optie wordt het gedrag van bestaande pijplijnen niet gewijzigd. Tags worden nog steeds gesynchroniseerd in deze pijplijnen, tenzij u de optie expliciet wijzigt, zoals hierboven beschreven.

Brown-outschema bijgewerkt voor Ubuntu 18.04-installatiekopieën

Azure Pipelines beëindigt de Ubuntu 18.04-installatiekopie (ubuntu-18.04) in onze gehoste pools. Deze installatiekopieën worden op 1 december buiten gebruik gesteld. Mogelijk worden er langere wachtrijtijden weergegeven.

Om u te helpen beter te bepalen welke pijplijnen de installatiekopie ubuntu-18.04 gebruiken, plannen we brown-outs. Taken mislukken tijdens een brown-outperiode.

  • Waarschuwingsberichten worden weergegeven bij pijplijnuitvoeringen met behulp van de installatiekopie ubuntu-18.04
  • Er is een script beschikbaar om u te helpen pijplijnen te vinden met behulp van afgeschafte installatiekopieën, waaronder ubuntu-18.04
  • We plannen korte "brownouts". Uitvoeringen van Ubuntu-18.04 mislukken tijdens de brown-outperiode. Daarom is het raadzaam om uw pijplijnen te migreren vóór de brown-outs.

Brownout-schema (bijgewerkt)

  • 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 maart 00.00 UTC - 7 maart 00.00 UTC
  • 13 maart 00.00 UTC - 14 maart 00.00 UTC
  • 21 maart 00.00 UTC - 22 maart 00.00 UTC

Volgende stappen

Notitie

Deze functies worden in de komende twee tot drie weken uitgerold.

Ga naar Azure DevOps en neem een kijkje.

Ga naar Azure DevOps

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het menu Help om een probleem te melden of een suggestie te geven.

Een suggestie doen

U kunt ook advies krijgen en uw vragen worden beantwoord door de community op Stack Overflow.

Met vriendelijke groet,

Aaron Hallberg