Rozwiązano wiele żądań z Developer Community

  • Artykuł

W odpowiedzi na Twoją opinię określiliśmy priorytety wielu funkcji, których zażądano w Developer Community. W usłudze Pipelines dodaliśmy obsługę funkcji podziału ciągu w wyrażeniu YAML. Ponadto pozwalamy teraz wyłączyć wyświetlanie ostatniego komunikatu zatwierdzenia dla uruchomienia potoku. W planach dostarczania zwiększyliśmy limit zespołu z 15 do 20.

Aby uzyskać szczegółowe informacje, zapoznaj się z informacjami o wersji.

Azure Boards

Azure Pipelines

Azure Boards

Zwiększanie limitu zespołu planów dostarczania z zakresu od 15 do 20

Plany dostarczania umożliwiają wyświetlanie wielu list prac i wielu zespołów w całej organizacji. Wcześniej można było wyświetlić 15 list prac zespołu, w tym mieszankę list prac i zespołów z różnych projektów. W tym przebiegu zwiększyliśmy maksymalny limit z 15 do 20.

Usunęliśmy usterkę w interfejsie API pobierania linków elementów roboczych raportowania, aby zwrócić poprawną wartość remoteUrl dla System.LinkTypes.Remote.Related typów linków. Przed tą poprawką zwracaliśmy nieprawidłową nazwę organizacji i brakujący identyfikator projektu.

Nowe poprawki błędów centrum tablic

W tym przebiegu usunęliśmy wiele usterek dla usługi New Boards Hub. Listę poprawek usterek można zobaczyć we wpisie w blogu New Boards Hub, Sprint 209 update (Nowy koncentrator usługi Boards Hub, sprint 209 aktualizacji).

Azure Pipelines

Wyłącz wyświetlanie ostatniego komunikatu zatwierdzenia dla uruchomienia potoku

Wcześniej interfejs użytkownika potoków był używany do wyświetlania ostatniego komunikatu zatwierdzenia podczas wyświetlania uruchomienia potoku.

Przykład ostatniego komunikatu zatwierdzenia

Ten komunikat może być mylący, na przykład gdy kod potoku YAML znajduje się w repozytorium innym niż ten, który przechowuje kod, który jest kompilujący. Wysłuchaliśmy opinii użytkowników z Developer Community z prośbą o włączenie/wyłączenie dołączania najnowszego komunikatu zatwierdzenia do tytułu każdego uruchomienia potoku.

Dzięki tej aktualizacji dodaliśmy nową właściwość YAML o nazwie appendCommitMessageToRunName, która pozwala to zrobić dokładnie. Domyślnie właściwość jest ustawiona na truewartość . Po ustawieniu go na false, uruchomienie potoku BuildNumberbędzie wyświetlać tylko .

Przykład uruchomienia potoku z numerem kompilacji

Przykład uruchomienia potoku z komunikatem ostatniego zatwierdzenia

Używane zasoby i parametry szablonu w interfejsie API REST przebiegów potoków

Rozszerzony interfejs API REST potoków uruchamia teraz zwraca więcej typów artefaktów używanych przez uruchomienie potoku oraz parametry używane do wyzwalania tego uruchomienia. Ulepszyliśmy interfejs API w celu zwrócenia container zasobów i pipeline oraz parametrów szablonu używanych w przebiegu potoku. Teraz możesz na przykład zapisywać testy zgodności, które oceniają repozytoria, kontenery i inne uruchomienia potoków używane przez potok.

Oto przykład nowej treści odpowiedzi.

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

Dodano obsługę funkcji podziału ciągu w wyrażeniach szablonów YAML

Potoki YAML zapewniają wygodne sposoby zmniejszania duplikacji kodu, takich jak zapętlanie wartości each listy lub właściwości obiektu.

Czasami zestaw elementów do iterowania jest reprezentowany jako ciąg. Na przykład gdy lista środowisk do wdrożenia jest definiowana przez ciąg integration1, integration2.

Gdy wysłuchaliśmy opinii użytkowników z Developer Community, słyszeliśmy, że potrzebujesz funkcji string split w wyrażeniach szablonów YAML.

Teraz możesz utworzyć ciąg i wykonać split iterację each po jego podciągach.

variables:
  environments: integration1, integration2

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

Nie synchronizuj tagów podczas pobierania repozytorium Git

Zadanie wyewidencjonowania używa --tags opcji pobierania zawartości repozytorium Git. Powoduje to pobranie wszystkich tagów przez serwer, a także wszystkich obiektów wskazywanych przez te tagi. Zwiększa to czas uruchamiania zadania w potoku — szczególnie w przypadku dużego repozytorium z wieloma tagami. Ponadto zadanie wyewidencjonowania synchronizuje tagi nawet wtedy, gdy włączysz opcję płytkiego pobierania, tym samym prawdopodobnie pokonując jego przeznaczenie. Aby zmniejszyć ilość danych pobranych lub ściągniętych z repozytorium Git, dodaliśmy teraz nową opcję do zadania w celu kontrolowania zachowania synchronizacji tagów. Ta opcja jest dostępna zarówno w potokach klasycznych, jak i YAML.

To zachowanie może być kontrolowane z pliku YAML lub z interfejsu użytkownika.

Aby zrezygnować z synchronizacji tagów za pośrednictwem pliku YAML, dodaj element fetchTags: false do kroku wyewidencjonowania. fetchTags Jeśli opcja nie jest określona, jest taka sama jak w przypadku fetchTags: true użycia.

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

Jeśli chcesz zmienić zachowanie istniejących potoków YAML, może być wygodniejsze ustawienie tej opcji w interfejsie użytkownika zamiast aktualizowania pliku YAML. Aby przejść do interfejsu użytkownika, otwórz edytor YAML dla potoku, wybierz pozycję Wyzwalacze, a następnie pozycję Przetwarzanie, a następnie krok Wyewidencjonuj.

Jeśli określisz to ustawienie zarówno w pliku YAML, jak i w interfejsie użytkownika, pierwszeństwo ma wartość określona w pliku YAML.

W przypadku wszystkich nowych potoków tworzonych (YAML lub Klasyczny) tagi są domyślnie synchronizowane. Ta opcja nie zmienia zachowania istniejących potoków. Tagi będą nadal synchronizowane w tych potokach, chyba że jawnie zmienisz opcję zgodnie z powyższym opisem.

Zaktualizowano harmonogram brownout dla obrazów z systemem Ubuntu 18.04

Usługa Azure Pipelines wycofuje obraz z systemem Ubuntu 18.04 (ubuntu-18.04) w naszych hostowanych pulach. Ten obraz zostanie wycofany 1 grudnia. Możesz zacząć widzieć dłuższe czasy kolejki.

Aby pomóc w lepszym zidentyfikowaniu potoków korzystających z obrazu ubuntu-18.04, planujemy brownouts. Zadania kończą się niepowodzeniem w okresie brownout.

  • Komunikaty ostrzegawcze są wyświetlane w przebiegach potoków przy użyciu obrazu ubuntu-18.04
  • Skrypt jest dostępny, aby ułatwić znajdowanie potoków przy użyciu przestarzałych obrazów, w tym ubuntu-18.04
  • Planujemy krótkie "brownouts". Każde uruchomienie ubuntu-18.04 zakończy się niepowodzeniem w okresie brownout. W związku z tym zaleca się migrowanie potoków przed zabarwieniami.

Harmonogram brownout (zaktualizowany)

  • 3 października 12:00 UTC — 3 października 14:00 UTC
  • 18 października 14:00 UTC — 18 października 16:00 UTC
  • 15 listopada, 18:00 UTC — 15 listopada, 20:00 UTC
  • 30 listopada 20:00 UTC — 30 listopada, 22:00 UTC
  • 15 grudnia 20:00 UTC — 16 grudnia 00:00 UTC
  • 5 stycznia 10.00 UTC — 5 stycznia 14.00 UTC
  • 13 stycznia 12.00 UTC — 13 stycznia 16.00 UTC
  • 18 stycznia 14.00 UTC — 18 stycznia 18.00 UTC
  • 24 stycznia 16.00 UTC — 24 stycznia 20.00 UTC
  • 1 lutego 18.00 UTC — 1 lutego 22.00 UTC
  • 7 lutego 16.00 UTC — 7 lutego 22.00 UTC
  • 13 lutego 14.00 UTC — 13 lutego 22.00 UTC
  • 21 lutego 10.00 UTC — 21 lutego 22.00 UTC
  • 28 lutego 10.00 UTC — 28 lutego 22.00 UTC
  • 6 marca 00,00 UTC — 7 marca 00,00 UTC
  • 13 marca 00,00 UTC — 14 marca 00,00 UTC
  • 21 marca 00,00 UTC — 22 marca 00,00 UTC

Następne kroki

Uwaga

Te funkcje będą wdrażane w ciągu najbliższych dwóch do trzech tygodni.

Przejdź do usługi Azure DevOps i spójrz.

Przejdź do usługi Azure DevOps

Jak przekazać opinię

Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.

Utwórz sugestię

Możesz również uzyskać porady i pytania, na które odpowiada społeczność w witrynie Stack Overflow.

Dzięki,

Aaron Hallberg