Číst v angličtině

Sdílet prostřednictvím

Vyřešení několika požadavků z Developer Community

  • Článek

V reakci na vaši zpětnou vazbu jsme upřednostnili několik funkcí, které jste v Developer Community požadovali. V části Pipelines jsme přidali podporu funkce rozdělení řetězců ve výrazu YAML. Kromě toho vám teď umožníme zakázat zobrazování poslední zprávy potvrzení pro spuštění kanálu. V části Delivery Plans jsme zvýšili limit pro tým z 15 na 20.

Podrobnosti najdete v poznámkách k verzi.

Azure Boards

Azure Pipelines

Azure Boards

Zvýšení limitu týmu Plánů doručení z 15 na 20

Plány doručení umožňují zobrazit více backlogů a více týmů v rámci vaší organizace. Dříve jste mohli zobrazit 15 týmových backlogů, včetně kombinace backlogů a týmů z různých projektů. V tomto sprintu jsme zvýšili maximální limit z 15 na 20.

Opravili jsme chybu v rozhraní API Pro generování sestav odkazů pracovní položky, která vrací správnou hodnotu remoteUrl pro System.LinkTypes.Remote.Related typy odkazů. Před touto opravou jsme vraceli nesprávný název organizace a chybějící ID projektu.

Nové opravy chyb centra Boards

V tomto sprintu jsme opravili několik chyb pro New Boards Hub. Seznam oprav chyb najdete v blogovém příspěvku New Boards Hub, Aktualizace Sprintu 209.

Azure Pipelines

Zákaz zobrazení poslední zprávy potvrzení pro spuštění kanálu

Dříve se uživatelské rozhraní kanálů používalo k zobrazení poslední zprávy o potvrzení při zobrazení spuštění kanálu.

Příklad poslední zprávy potvrzení

Tato zpráva může být matoucí, například když se kód kanálu YAML nachází v jiném úložišti než v úložišti, které obsahuje kód, který vytváří. Vyslyšeli jsme vaši zpětnou vazbu od Developer Community s žádostí o způsob, jak povolit nebo zakázat připojení nejnovější zprávy o potvrzení k názvu každého spuštění kanálu.

S touto aktualizací jsme přidali novou vlastnost YAML s názvem appendCommitMessageToRunName, která vám umožní přesně to udělat. Ve výchozím nastavení je vlastnost nastavená na true. Když ho nastavíte na false, zobrazí se při spuštění kanálu pouze BuildNumber.

Příklad spuštění kanálu s číslem sestavení

Příklad spuštění kanálu se zprávou o posledním potvrzení

Spotřebované prostředky a parametry šablony v rozhraní REST API spuštění kanálů

Rozšířené rozhraní REST API pro spouštění kanálů teď vrací více typů artefaktů používaných spuštěním kanálu a parametry použité k aktivaci tohoto spuštění. Vylepšili jsme rozhraní API tak, aby vracela container prostředky a pipeline parametry šablony použité při spuštění kanálu. Teď můžete například zapisovat kontroly dodržování předpisů, které vyhodnocují úložiště, kontejnery a další spuštění kanálu používaná kanálem.

Tady je příklad nového textu odpovědi.

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

Přidání podpory pro funkci dělení řetězců ve výrazech šablony YAML

Kanály YAML poskytují pohodlné způsoby, jak omezit duplikaci kódu, jako je například procházení each hodnot seznamu nebo vlastnosti objektu.

V některých případech je sada položek, kterými se má iterovat, reprezentována jako řetězec. Například když je seznam prostředí, do které se má nasadit, definovaný řetězcem integration1, integration2.

Když jsme si vyslechli vaši zpětnou vazbu od Developer Community, slyšeli jsme, že ve výrazech šablon YAML požadujete řetězcovou split funkci.

Teď můžete split vytvořit řetězec a iterovat each jeho podřetězce.

YAML 
variables:
  environments: integration1, integration2

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

Nesynchronizovat značky při načítání úložiště Git

Úloha rezervace používá --tags možnost při načítání obsahu úložiště Git. To způsobí, že server načte všechny značky a také všechny objekty, na které tyto značky odkazuje. Tím se prodlužuje doba spuštění úlohy v kanálu – zejména pokud máte velké úložiště s několika značkami. Kromě toho úloha pokladny synchronizuje značky i v případě, že povolíte možnost mělkého načtení, čímž může dojít k ukončení jejího účelu. Abychom snížili množství dat načtených nebo načítaných z úložiště Git, přidali jsme do úlohy novou možnost, která řídí chování synchronizace značek. Tato možnost je k dispozici v klasických kanálech i kanálech YAML.

Toto chování může být řízeno ze souboru YAML nebo z uživatelského rozhraní.

Pokud chcete zrušit synchronizaci značek prostřednictvím souboru YAML, přidejte fetchTags: false do kroku rezervace příkaz . fetchTags Pokud možnost není zadaná, je stejná, jako kdyby fetchTags: true se použila.

YAML 
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

Pokud chcete změnit chování existujících kanálů YAML, může být vhodnější nastavit tuto možnost v uživatelském rozhraní místo aktualizace souboru YAML. Pokud chcete přejít do uživatelského rozhraní, otevřete editor YAML pro kanál, vyberte Aktivační události, pak Proces a pak krok Rezervace.

Pokud toto nastavení zadáte v souboru YAML i v uživatelském rozhraní, bude mít přednost hodnota zadaná v souboru YAML.

U všech nových kanálů, které vytvoříte (YAML nebo Classic), se značky stále synchronizují ve výchozím nastavení. Tato možnost nemění chování existujících kanálů. Značky se v těchto kanálech budou dál synchronizovat, pokud explicitně nezměníte možnost, jak je popsáno výše.

Aktualizace plánu brownout pro image Ubuntu 18.04

Azure Pipelines v hostovaných fondech vyřazuje image Ubuntu 18.04 (ubuntu-18.04). Tento obrázek bude vyřazen 1. prosince. Může se stát, že se zobrazí delší časy fronty.

Abychom vám pomohli lépe identifikovat, které kanály používají image ubuntu-18.04, plánujeme brownouty. Úlohy selžou během období brownoutu.

  • Varovné zprávy se zobrazují při spuštění kanálu pomocí image ubuntu-18.04.
  • K dispozici je skript , který vám pomůže najít kanály pomocí zastaralých imagí, včetně ubuntu-18.04.
  • Plánujeme krátké "brownouty". Všechna spuštění ubuntu-18.04 se během období brownoutu nezdaří. Proto se doporučuje migrovat kanály před výpadky.

Plán brownoutu (aktualizováno)

  • 3. října, 12:00 UTC–3. října, 14:00 UTC
  • 18. října, 14:00 UTC–18. října, 16:00 UTC
  • 15. listopadu, 18:00 UTC–15. listopadu, 20:00 UTC
  • 30. listopadu, 20:00 UTC–30. listopadu, 22:00 UTC
  • 15. prosince, 20:00 UTC–16. prosince 00:00 UTC
  • 5. ledna, 10:00 UTC –5. ledna 14:00 UTC
  • 13. ledna, 12:00 UTC–13. ledna, 16:00 UTC
  • 18. ledna, 14:00 UTC – 18. ledna, 18:00 UTC
  • 24. ledna, 16:00 UTC –24. ledna, 20:00 UTC
  • 1. února, 18:00 UTC –1. února 22:00 UTC
  • 7. února, 16:00 UTC –7. února 22:00 UTC
  • 13. února, 14:00 UTC –13. února 22:00 UTC
  • 21. února, 10:00 UTC – 21. února, 22:00 UTC
  • 28. února, 10:00 UTC–28. února 22:00 UTC
  • 6. března, 00:00 UTC – 7. března 00:00 UTC
  • 13. března, 00:00 UTC – 14. března, 00:00 UTC
  • 21. března, 00:00 UTC – 22. března 00:00 UTC

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.

Vytvoření návrhu

Můžete také získat rady a odpovědi na vaše otázky od komunity na Webu Stack Overflow.

Díky,

Aaron Hallberg