Ulepszony interfejs API w wersji zapoznawczej YAML i konfigurowanie nadrzędnego źródła dla pakietów uniwersalnych
W tym przebiegu wprowadzamy nowy punkt końcowy interfejsu API, który umożliwia pobranie finalizowanej treści YAML. Z przyjemnością ogłaszamy również, że dodamy możliwość konfigurowania nadrzędnego źródła dla pakietów uniwersalnych w tej wersji.
Aby uzyskać szczegółowe informacje, zapoznaj się z listą funkcji poniżej.
Funkcje
Azure Boards
- Typy elementów roboczych systemu w ramach listy prac i na tablicach
- Zdarzenie rejestrowania inspekcji
- Zwiększenie limitu repozytorium aplikacji usługi GitHub dla usługi Azure Boards (prywatna wersja zapoznawcza)
- Dostosowywanie stanu elementu roboczego, gdy żądanie ściągnięcia zostanie scalone (prywatna wersja zapoznawcza)
Azure Pipelines
- Ogłoszenia dotyczące potoków usługi Pipelines
- Ulepszone przekazywanie dziennika agenta
- Opcjonalne instalowanie woluminów kontenerów tylko do odczytu
- Szczegółowa kontrola nad procesem uruchamiania/zatrzymywania kontenera
- Rozpakowywanie pakietów zadań dla poszczególnych kroków
- Ulepszenie zabezpieczeń wersji dzięki ograniczeniu zakresu tokenów dostępu
- Ulepszenia interfejsu API podglądu języka YAML
Azure Artifacts
- Konfigurowanie nadrzędnych źródeł danych na potrzeby pakietów uniwersalnych
- Interfejs API REST aktualizacji wersji pakietu jest teraz dostępny dla pakietów narzędzia Maven
Azure Boards
Typy elementów roboczych systemu w ramach listy prac i na tablicach
Uruchomiliśmy prywatną wersję zapoznawcza funkcji, która umożliwia dodanie typu elementu roboczego systemu do wybranego poziomu listy prac. Historycznie te typy elementów roboczych były dostępne tylko z zapytań.
| Przetwarzaj | Typ elementu roboczego |
|---|---|
| Zwinność | Problem |
| Scrum | Przeszkody |
| CMMI | Żądanie zmiany |
| Problem | |
| Wykonaj przegląd | |
| Ryzyko |
Z przyjemnością informujemy, że funkcja jest obecnie dostępna w wersji zapoznawczej i ogólnie dostępna dla wszystkich organizacji. Dodawanie typu elementu roboczego systemu do poziomu listy prac jest proste. Wystarczy przejść do procesu niestandardowego i kliknąć kartę Poziomy listy prac. Wybierz wybrany poziom listy prac (na przykład: Listę prac wymagań) i wybierz opcję edycji. Następnie dodaj typ elementu roboczego.
Zdarzenie rejestrowania inspekcji
Dodaliśmy nowe zdarzenie do dzienników inspekcji, aby ułatwić klientom lepsze śledzenie zmian związanych z procesem. Zdarzenie będzie rejestrowane za każdym razem, gdy wartości na liście wyboru zostaną zmienione. Zmiany pól listy wyboru są zwykle najczęściej wprowadzane w procesie. Dzięki temu nowemu zdarzeniu administratorzy organizacji mogą lepiej śledzić, kiedy i kto wprowadzał zmiany w tych polach.
Zwiększenie limitu repozytorium aplikacji usługi GitHub dla usługi Azure Boards (prywatna wersja zapoznawcza)
Jeśli używasz aplikacji usługi Azure Boards z witryny GitHub Marketplace, istnieje limit 100 repozytoriów GitHub, z którymi można nawiązać połączenie. Staje się to blokadą dla dużych organizacji, które mogą mieć ponad 100 repozytoriów. W tym przebiegu zmieniliśmy sposób łączenia usługi Azure Boards z repozytoriami Usługi GitHub w celu obsługi ponad 100. Jeśli obecnie osiągasz limit 100 repozytoriów, daj nam znać i możemy umożliwić funkcji zwiększenie tego limitu i odblokowanie. Wyślij nam wiadomość e-mail bezpośrednio z twoją nazwą organizacji (dev.azure.com/{organizacja}).
Dostosowywanie stanu elementu roboczego, gdy żądanie ściągnięcia zostanie scalone (prywatna wersja zapoznawcza)
Nie wszystkie przepływy pracy są takie same. Niektórzy klienci chcą zamknąć powiązane elementy robocze po zakończeniu żądania ściągnięcia. Inne osoby chcą ustawić elementy robocze na inny stan, który ma zostać zweryfikowany przed zamknięciem. Powinniśmy pozwolić na oba te elementy.
Począwszy od przebiegu 174, mamy nową funkcję, która umożliwia ustawienie elementów roboczych na żądany stan po scaleniu i zakończeniu żądania ściągnięcia. W tym celu przeskanujemy opis żądania ściągnięcia i wyszukamy wartość stanu, po której następuje #mention elementów roboczych. W tym przykładzie ustawiamy dwa scenariusze użytkownika na Rozwiązane i zamykamy dwa zadania.
Ta funkcja od dawna nadchodzi i jesteśmy podekscytowani, aby zobaczyć, co myślisz. Aby rozpocząć, po prostu skanujemy opis żądania ściągnięcia i nie uwzględniamy żadnych zmian interfejsu użytkownika. Chcieliśmy najpierw uzyskać twoją opinię przed dalszym inwestowaniem.
Jeśli interesuje Cię uczestnictwo w prywatnej wersji zapoznawczej , wyślij nam bezpośrednio wiadomość e-mail. Nie zapomnij dołączyć organizacji (dev.azure.com/{organization}).
Azure Pipelines
Ogłoszenia dotyczące potoków usługi Pipelines
Uwaga
Obrazy usługi Azure Pipelines są stale aktualizowane w celu zapewnienia użytkownikom najlepszego środowiska. Te rutynowe aktualizacje mają głównie na celu rozwiązywanie problemów z usterkami lub nieaktualnym oprogramowaniem. Często nie mają one wpływu na potoki, jednak nie zawsze tak jest. Może to mieć wpływ na potok, jeśli pobiera zależność od oprogramowania, które zostało usunięte lub zaktualizowane na obrazie.
Aby dowiedzieć się więcej na temat nadchodzących aktualizacji na naszych obrazach systemów Windows, Linux i macOS, przeczytaj następujące ogłoszenia:
Aby wyświetlić informacje o wersji dla nadchodzących (w wersji wstępnej) i wdrożonych zmian, zasubskrybuj następujące informacje o wersji:
Ulepszone przekazywanie dziennika agenta
Gdy agent przestanie komunikować się z serwerem usługi Azure Pipelines, zadanie, które zostało uruchomione, zostanie porzucone. Jeśli zdarzyło Ci się przeglądać dzienniki konsoli przesyłania strumieniowego, być może masz pewne wskazówki dotyczące tego, co agent był aż do prawej, zanim przestał odpowiadać. Ale jeśli nie, lub jeśli odświeżyłeś stronę, te dzienniki konsoli znikną. W tej wersji, jeśli agent przestanie odpowiadać przed wysłaniem pełnych dzienników, zachowamy dzienniki konsoli jako następną najlepszą rzeczą. Dzienniki konsoli są ograniczone do 1000 znaków na wiersz i czasami mogą być niekompletne, ale są one o wiele bardziej przydatne niż pokazywanie niczego! Badanie tych dzienników może pomóc w rozwiązywaniu problemów z własnymi potokami i z pewnością pomoże naszym inżynierom pomocy technicznej w rozwiązywaniu problemów.
Opcjonalne instalowanie woluminów kontenerów tylko do odczytu
Po uruchomieniu zadania kontenera w usłudze Azure Pipelines kilka woluminów zawierających obszar roboczy, zadania i inne materiały są mapowane jako woluminy. Te woluminy domyślnie mają dostęp do odczytu/zapisu. W celu zwiększenia bezpieczeństwa można zainstalować woluminy tylko do odczytu, zmieniając specyfikację kontenera w języku YAML. Dla każdego klucza w obszarze mountReadOnly można ustawić wartość tylko do true odczytu (wartość domyślna to false).
resources:
containers:
- container: example
image: ubuntu:18.04
mountReadOnly:
externals: true
tasks: true
tools: true
work: false
Szczegółowa kontrola nad procesem uruchamiania/zatrzymywania kontenera
Ogólnie rzecz biorąc, zalecamy umożliwienie usłudze Azure Pipelines zarządzania cyklem życia zadań i kontenerów usług. Jednak w niektórych nietypowych scenariuszach możesz zacząć i zatrzymać je samodzielnie. W tej wersji utworzyliśmy tę funkcję w zadaniu platformy Docker.
Oto przykładowy potok korzystający z nowej możliwości:
resources:
containers:
- container: builder
image: ubuntu:18.04
steps:
- script: echo "I can run inside the container (it starts by default)"
target:
container: builder
- task: Docker@2
inputs:
command: stop
container: builder
# if any step tried to run in the container here, it would fail
Ponadto uwzględniamy listę kontenerów w zmiennej potoku . Agent.ContainerMapping Możesz to użyć, jeśli chcesz sprawdzić listę kontenerów w skry skrycie, na przykład. Zawiera on ciągyfikowany obiekt JSON mapowania nazwy zasobu ("builder" z powyższego przykładu) na identyfikator kontenera, którym zarządza agent.
Rozpakowywanie pakietów zadań dla poszczególnych kroków
Gdy agent uruchamia zadanie, najpierw pobiera wszystkie pakiety zadań wymagane przez kroki zadania. Zwykle w przypadku wydajności rozpakowuje zadania raz na zadanie, nawet jeśli zadanie jest używane w wielu krokach. Jeśli masz obawy dotyczące niezaufanego kodu zmieniającego rozpakowaną zawartość, możesz wymienić trochę wydajności, rozpakowując zadanie przy każdym użyciu. Aby włączyć ten tryb, należy przekazać --alwaysextracttask go podczas konfigurowania agenta.
Ulepszenie zabezpieczeń wersji dzięki ograniczeniu zakresu tokenów dostępu
Opierając się na naszej inicjatywie w celu ulepszenia ustawień zabezpieczeń dla usługi Azure Pipelines, obsługujemy teraz ograniczanie zakresu tokenów dostępu dla wersji.
Każde zadanie uruchamiane w wersjach pobiera token dostępu. Token dostępu jest używany przez zadania i skrypty do wywołania z powrotem do usługi Azure DevOps. Na przykład użyjemy tokenu dostępu, aby uzyskać kod źródłowy, pobrać artefakty, przekazać dzienniki, wyniki testów lub wykonać wywołania REST do usługi Azure DevOps. Nowy token dostępu jest generowany dla każdego zadania i wygasa po zakończeniu zadania.
Dzięki tej aktualizacji zwiększamy bezpieczeństwo potoku, ograniczając zakres tokenów dostępu i rozszerzając je na wersje klasyczne.
Ta funkcja będzie domyślnie włączona dla nowych projektów i organizacji. W przypadku istniejących organizacji należy ją włączyć w usłudze Organization Ustawienia Pipelines > Ustawienia>. > Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków wydania. Dowiedz się więcej tutaj.
Ulepszenia interfejsu API podglądu języka YAML
Kilka przebiegów temu wprowadziliśmy możliwość wyświetlania podglądu kompletnego kodu YAML potoku bez jego uruchamiania. Dzięki tej aktualizacji utworzyliśmy dedykowany nowy adres URL dla funkcji w wersji zapoznawczej. Teraz możesz utworzyć post, aby https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview pobrać sfinalizowaną treść YAML. Ten nowy interfejs API przyjmuje te same parametry co kolejkowanie przebiegu, ale nie wymaga już uprawnienia "Kompilacje kolejki".
Azure Artifacts
Konfigurowanie nadrzędnych źródeł danych na potrzeby pakietów uniwersalnych
Teraz możesz skonfigurować źródła danych usługi Azure Artifacts, aby automatycznie pobierać pakiety uniwersalne ze źródeł nadrzędnych na żądanie.
Wcześniej można było skonfigurować źródła nadrzędne dla pakietów NuGet, Python, Maven i npm, ale nie dla pakietów uniwersalnych. Wynikało to z różnicy w technologii magazynowania używanej dla pakietów uniwersalnych, które obsługują znacznie większe pakiety niż inne obsługiwane typy pakietów.
Teraz można skonfigurować źródła nadrzędne dla pakietów uniwersalnych w taki sam sposób jak w przypadku innych typów pakietów; otwórz ustawienia kanału informacyjnego, kliknij pozycję Źródła nadrzędne —> Dodaj źródło nadrzędne —> i wybierz odpowiedni typ źródła. Pakiety uniwersalne (UPack) będą widoczne jako nowa opcja w następnym widoku (zobacz obraz poniżej). Aby uzyskać więcej informacji, zobacz dokumentację konfiguracji nadrzędnych źródeł.
Należy pamiętać, że pakiety uniwersalne w źródłach nadrzędnych są obsługiwane tylko między kanałami informacyjnymi w tej samej organizacji DevOps.
Interfejs API REST aktualizacji wersji pakietu jest teraz dostępny dla pakietów narzędzia Maven
Teraz możesz użyć interfejsu API REST "Aktualizuj wersję pakietu" w usłudze Azure Artifacts, aby zaktualizować wersje pakietu Maven. Wcześniej można było użyć interfejsu API REST do aktualizowania wersji pakietów NuGet, Maven, npm i Universal Packages, ale nie pakietów Maven.
Aby zaktualizować pakiety Maven, użyj polecenia HTTP PATCH w następujący sposób.
PATCH
https://pkgs.dev.azure.com/{organization}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1
Można ustawić następujące ustawienia:
Parametry identyfikatora URI
| Nazwa/nazwisko | In | Wymagane | Type | Opis |
|---|---|---|---|---|
| artifactId | path | PRAWDA | string | Identyfikator artefaktu pakietu |
| źródło | path | PRAWDA | string | Nazwa lub identyfikator kanału informacyjnego |
| groupId | path | PRAWDA | string | Identyfikator grupy pakietu |
| organization | path | PRAWDA | string | Nazwa organizacji usługi Azure DevOps |
| version | path | PRAWDA | string | Wersja pakietu |
| projekt | path | string | Identyfikator projektu lub nazwa projektu | |
| api-version | zapytanie | PRAWDA | string | Wersja interfejsu API do użycia. Należy ustawić wartość "5.1-preview.1", aby użyć tej wersji interfejsu API |
Treść żądania
| Nazwa/nazwisko | Typ | Opis |
|---|---|---|
| widoki | JsonPatchOperation | Widok, do którego zostanie dodana wersja pakietu |
Aby uzyskać więcej informacji, zapoznaj się z dokumentacją interfejsu API REST podczas aktualizowania.
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 przyjrzyj się.
Jak przekazać opinię
Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.
Możesz również uzyskać porady i odpowiedzi na pytania społeczności w witrynie Stack Overflow.
Dzięki,
Aaron Hallberg