Delen via

Verbeterde YAML Preview-API en upstream-bron configureren voor universele pakketten

  • Artikel

In deze sprint implementeren we een nieuw API-eindpunt waarmee u de voltooide YAML-hoofdtekst kunt ophalen. We zijn ook verheugd om aan te kondigen dat we de mogelijkheid toevoegen om uw upstream-bron te configureren voor universele pakketten met deze release.

Bekijk de onderstaande lijst met functies voor meer informatie.

Functies

Azure Boards

Azure-pipelines

Azure Artifacts

Azure Boards

Typen systeemwerkitems voor achterstand en boards

We hebben een persoonlijke preview gestart van een functie waarmee u een systeemwerkitemtype kunt toevoegen aan het achterstandsniveau van de keuze. Deze typen werkitems zijn in het verleden alleen beschikbaar vanuit query's.

Proces Type werkitem
Flexibel Probleem
Scrum Belemmering
CMMI Wijzigingsaanvraag
Probleem
Beoordelen
Risico

We zijn blij om aan te kondigen dat de functie nu niet meer beschikbaar is als preview-versie en algemeen beschikbaar is voor alle organisaties. Het toevoegen van een systeemwerkitemtype aan een achterstandsniveau is eenvoudig. Ga naar het aangepaste proces en klik op het tabblad Achterstandsniveaus. Selecteer het gewenste achterstandsniveau (bijvoorbeeld: Vereistenachterstand) en kies de bewerkingsoptie. Voeg vervolgens het type werkitem toe.

backlogs

Gebeurtenis voor auditlogboekregistratie

We hebben een nieuwe gebeurtenis toegevoegd aan de auditlogboeken om klanten te helpen processen gerelateerde wijzigingen beter bij te houden. Een gebeurtenis wordt geregistreerd wanneer de waarden op een selectielijst worden gewijzigd. Wijzigingen in selectielijstvelden zijn meestal de meest voorkomende wijzigingen in een proces. Met deze nieuwe gebeurtenis kunnen organisatiebeheerders beter bijhouden wanneer en wie wijzigingen heeft aangebracht in deze velden.

audit-logs

Limiet voor opslagplaats van GitHub-apps voor Azure Boards verhoogd (beperkte preview)

Als u de Azure Boards-toepassing van de GitHub Marketplace gebruikt, is er een limiet van 100 GitHub-opslagplaatsen waarmee u verbinding kunt maken.  Dit wordt een obstakel voor grote organisaties die ruim 100 opslagplaatsen kunnen hebben. In deze sprint hebben we gewijzigd hoe Azure Boards verbinding maakt met uw GitHub-opslagplaatsen om meer dan 100 te ondersteunen. Als u momenteel de limiet van 100 opslagplaatsen bereikt, laat het ons dan weten en kunnen we de functie inschakelen om die limiet te verhogen en de blokkering op te heffen. Stuur ons rechtstreeks een e-mail met de naam van uw organisatie (dev.azure.com/{organization}).

De status van het werkitem aanpassen wanneer een pull-aanvraag wordt samengevoegd (beperkte preview)

Niet alle werkstromen zijn hetzelfde. Sommige klanten willen hun gerelateerde werkitems sluiten wanneer een pull-aanvraag is voltooid. Anderen willen de werkitems instellen op een andere status die moet worden gevalideerd voordat ze worden gesloten. We moeten beide toestaan.

Vanaf sprint 174 hebben we een nieuwe functie waarmee u de werkitems kunt instellen op de gewenste status wanneer de pull-aanvraag wordt samengevoegd en voltooid. Hiervoor scannen we de beschrijving van de pull-aanvraag en zoeken we naar de statuswaarde gevolgd door de #mention van de werkitems. In dit voorbeeld stellen we twee gebruikersverhalen in op Opgelost en sluiten we twee taken.

work-item-state

Deze functie is al lange tijd beschikbaar en we zijn verheugd om te zien wat u ervan vindt. Om te beginnen scannen we alleen de beschrijving van de pull-aanvraag en bevatten we geen wijzigingen in de gebruikersinterface. We wilden eerst uw feedback ontvangen voordat we verder investeren.

Als u geïnteresseerd bent in deelname aan de persoonlijke preview , stuur ons dan rechtstreeks een e-mail. Vergeet niet om uw organisatie op te nemen (dev.azure.com/{organization}).

Azure-pipelines

Aankondigingen van pijplijninstallatiekopieën

Notitie

Installatiekopieën van Azure Pipelines worden voortdurend bijgewerkt om gebruikers de best mogelijke ervaring te bieden. Deze routine-updates zijn voornamelijk gericht op het aanpakken van bugs of verouderde software. Ze hebben vaak geen invloed op uw pijplijnen, maar dit is niet altijd het geval. Uw pijplijn kan worden beïnvloed als er een afhankelijkheid nodig is van een stuk software dat is verwijderd of bijgewerkt op de installatiekopieën.

Lees de volgende aankondigingen voor meer informatie over toekomstige updates in onze Windows-, Linux- en macOS-installatiekopieën:

Als u opmerkingen bij de release wilt weergeven voor aanstaande (voorlopige versie) en geïmplementeerde wijzigingen, abonneert u zich op de volgende releaseopmerkingen:

Uploads van agentlogboek verbeterd

Wanneer een agent stopt met communiceren met de Azure Pipelines-server, wordt de taak die wordt uitgevoerd, afgetrokken. Als u toevallig de logboeken van de streamingconsole bekijkt, hebt u misschien wat aanwijzingen gekregen over wat de agent precies aan de hand had voordat deze niet meer reageerde. Maar als u dat niet was, of als u de pagina vernieuwde, waren die consolelogboeken verdwenen. Als de agent niet meer reageert voordat de volledige logboeken worden verzonden, bewaren we de consolelogboeken als het beste. Consolelogboeken zijn beperkt tot 1000 tekens per regel en kunnen af en toe onvolledig zijn, maar ze zijn veel nuttiger dan niets weergeven. Het onderzoeken van deze logboeken kan u helpen bij het oplossen van problemen met uw eigen pijplijnen en het zal onze ondersteuningstechnici zeker helpen bij het oplossen van problemen.

Containervolumes optioneel koppelen als alleen-lezen

Wanneer u een containertaak uitvoert in Azure Pipelines, worden verschillende volumes met de werkruimte, taken en andere materialen toegewezen als volumes. Deze volumes zijn standaard ingesteld op lees-/schrijftoegang. Voor betere beveiliging kunt u de volumes koppelen met het kenmerk Alleen-lezen door de containerspecificatie in YAML te wijzigen. Elke sleutel kan mountReadOnly worden ingesteld true op alleen-lezen (de standaardwaarde is false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Nauwkeurige controle over starten/stoppen van containers

Over het algemeen raden we u aan Azure Pipelines toe te staan de levenscyclus van uw taak- en servicecontainers te beheren. In sommige ongebruikelijke scenario's wilt u deze echter zelf starten en stoppen. Met deze release hebben we die mogelijkheid ingebouwd in de Docker-taak.

Hier volgt een voorbeeldpijplijn met behulp van de nieuwe mogelijkheid:

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

Daarnaast bevatten we de lijst met containers in een pijplijnvariabele. Agent.ContainerMapping U kunt dit gebruiken als u bijvoorbeeld de lijst met containers in een script wilt inspecteren. Het bevat een tekenreeks-JSON-object dat de resourcenaam ('builder' uit het bovenstaande voorbeeld) toegeeft aan de container-id die de agent beheert.

Taakbundels decomprimeren voor elke stap

Wanneer de agent een taak uitvoert, worden eerst alle taakbundels gedownload die nodig zijn voor de stappen van de taak. Normaal gesproken worden voor prestaties de taken eenmaal per taak uitgepakt, zelfs als de taak in meerdere stappen wordt gebruikt. Als u zich zorgen maakt over niet-vertrouwde code die de uitgepakte inhoud wijzigt, kunt u een beetje prestaties wegruilen door de agent de taak voor elk gebruik uit te pakken. Als u deze modus wilt inschakelen, geeft u door --alwaysextracttask wanneer u de agent configureert.

Beveiliging van release verbeteren door het bereik van toegangstokens te beperken

Voortbouwend op ons initiatief om beveiligingsinstellingen voor Azure Pipelines te verbeteren, bieden we nu ondersteuning voor het beperken van het bereik van toegangstokens voor releases.

Elke taak die in releases wordt uitgevoerd, krijgt een toegangstoken. Het toegangstoken wordt gebruikt door de taken en door uw scripts om terug te bellen naar Azure DevOps. We gebruiken bijvoorbeeld het toegangstoken om broncode op te halen, artefacten te downloaden, logboeken te uploaden, testresultaten te testen of OM REST-aanroepen naar Azure DevOps uit te voeren. Er wordt een nieuw toegangstoken gegenereerd voor elke taak en het verloopt zodra de taak is voltooid.

Met deze update bouwen we voort op het verbeteren van de beveiliging van pijplijnen door het bereik van toegangstokens te beperken en hetzelfde uit te breiden naar klassieke releases.

Deze functie is standaard ingeschakeld voor nieuwe projecten en organisaties. Voor bestaande organisaties moet u deze inschakelen in Organisatie Instellingen > Pipelines > Instellingen. > Beperk het bereik voor taakautorisatie tot het huidige project voor releasepijplijnen. U vindt hier meer informatie.

Verbeteringen in YAML preview-API

Een paar sprints geleden hebben we de mogelijkheid geïntroduceerd om een voorbeeld van de volledige YAML van een pijplijn te bekijken zonder deze uit te voeren. Met deze update hebben we een speciale nieuwe URL gemaakt voor de preview-functie. Nu kunt u POST posten om de voltooide YAML-hoofdtekst op te https://dev.azure.com/{org}/{project}/_apis/pipelines/{pipelineId}/preview halen. Deze nieuwe API gebruikt dezelfde parameters als het in de wachtrij plaatsen van een uitvoering, maar vereist niet langer de machtiging 'Queue builds'.

Azure Artifacts

Upstreambronnen voor universele pakketten configureren

U kunt nu uw Azure Artifacts-feeds configureren om universal packages automatisch te downloaden van upstream-bronnen op aanvraag.

Voorheen kunt u upstream-bronnen configureren voor NuGet-, Python-, Maven- en NPM-pakketten, maar niet voor Universal Packages. Dit werd veroorzaakt door een verschil in de opslagtechnologie die wordt gebruikt voor Universal Packages, die veel grotere pakketten ondersteunen dan andere ondersteunde pakkettypen.

U kunt nu upstream-bronnen configureren voor Universal Packages op dezelfde manier als voor andere pakkettypen; open de instellingen van uw feed, klik op Upstream-bronnen ->Upstream-bron> toevoegen en kies het brontype dat geschikt is voor u. U ziet Universal Packages (UPack) als een nieuwe optie in de volgende weergave (zie de onderstaande afbeelding). Zie de configuratiedocumentatie voor upstream-bronnen voor meer informatie.

upack

Universal Packages in upstream-bronnen worden alleen ondersteund tussen feeds in dezelfde DevOps-organisatie.

REST API-versie van updatepakket nu beschikbaar voor Maven-pakketten

U kunt nu de REST API updatepakketversie van Azure Artifacts gebruiken om Maven-pakketversies bij te werken. Voorheen kon u de REST API gebruiken om pakketversies bij te werken voor NuGet-, Maven-, npm- en Universal Packages, maar niet voor Maven-pakketten.

Als u Maven-pakketten wilt bijwerken, gebruikt u de HTTP PATCH-opdracht als volgt.

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

U kunt het volgende instellen:

URI-parameters

Naam In Vereist Type Beschrijving
artifactId path TRUE tekenreeks Artefact-id van het pakket
feed path TRUE tekenreeks Naam of id van de feed
groupId path TRUE tekenreeks Groeps-id van het pakket
organization path TRUE tekenreeks De naam van de Azure DevOps-organisatie
version path TRUE tekenreeks Versie van het pakket
project path tekenreeks Project-id of projectnaam
api-versie query TRUE tekenreeks De versie van de API die moet worden gebruikt. Dit moet worden ingesteld op '5.1-preview.1' om deze versie van de API te gebruiken

Hoofdtekst van aanvraag

Naam Type Beschrijving
weergaven JsonPatchOperation De weergave waaraan de pakketversie wordt toegevoegd

Raadpleeg de REST API-documentatie voor meer informatie wanneer deze wordt bijgewerkt.

Volgende stappen

Notitie

Deze functies worden de komende twee tot drie weken uitgerold.

Ga naar Azure DevOps en kijk eens.

Ga naar Azure DevOps

Feedback geven

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

Make a suggestion

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

Met vriendelijke groet,

Aaron Hallberg