Aktivitetstyper och användning

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

Kommentar

Microsoft Visual Studio Team Foundation Server 2018 och tidigare versioner har följande skillnader i namngivning:

  • Pipelines för build och release kallas definitioner
  • Körningar kallas byggen
  • Tjänstanslutningar kallas tjänstslutpunkter
  • Faser kallas miljöer
  • Jobb kallas faser

En uppgift utför en åtgärd i en pipeline och är ett paketerat skript eller en procedur som är abstrakt med en uppsättning indata. Uppgifter är byggstenarna för att definiera automatisering i en pipeline.

När du lägger till en uppgift i pipelinen kan den också lägga till en uppsättning krav i pipelinen. Kraven definierar de krav som måste installeras på agenten för att aktiviteten ska kunna köras. När du kör bygget eller distributionen väljs en agent som uppfyller dessa krav.

När du kör ett jobb körs alla aktiviteter i följd, en efter en. Information om hur du kör samma uppsättning aktiviteter parallellt på flera agenter eller för att köra vissa uppgifter utan att använda en agent finns i jobb.

Som standard körs alla aktiviteter i samma kontext, oavsett om det är på värden eller i en jobbcontainer.

Du kan också använda stegmål för att styra kontexten för en enskild uppgift.

Läs mer om hur du anger egenskaper för en uppgift med de inbyggda aktiviteterna.

När du kör ett jobb körs alla aktiviteter i följd, en efter en, på en agent. Information om hur du kör samma uppsättning aktiviteter parallellt på flera agenter eller för att köra vissa uppgifter utan att använda en agent finns i jobb.

Mer information om de allmänna attribut som stöds av aktiviteter finns i YAML-referensen för steps.task.

Anpassade uppgifter

Azure DevOps innehåller inbyggda uppgifter för att möjliggöra grundläggande bygg- och distributionsscenarier. Du kan också skapa en egen anpassad uppgift.

Dessutom erbjuder Visual Studio Marketplace många tillägg. Var och en av dem utökar aktivitetskatalogen med en eller flera aktiviteter när de installeras i din prenumeration eller samling. Du kan också skriva egna anpassade tillägg för att lägga till uppgifter i Azure Pipelines.

I YAML-pipelines refererar du till uppgifter efter namn. Om ett namn matchar både en in-box-uppgift och en anpassad uppgift har den inbyggda aktiviteten företräde. Du kan använda aktivitets-GUID eller ett fullständigt kvalificerat namn för den anpassade aktiviteten för att undvika den här risken:

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

Om du vill hitta myPublisherId och väljer du Get on a task in the marketplace (Hämta på en myExtensionIduppgift på marketplace). Värdena efter i URL-strängen itemName är myPublisherId och myExtensionId. Du kan också hitta det fullständigt kvalificerade namnet genom att lägga till uppgiften i en versionspipeline och välja Visa YAML när du redigerar uppgiften.

Uppgiftsversioner

Aktiviteter är versionshanterade och du måste ange huvudversionen av uppgiften som används i pipelinen. Detta kan bidra till att förhindra problem när nya versioner av en uppgift släpps. Uppgifter är vanligtvis bakåtkompatibla, men i vissa scenarier kan det uppstå oförutsägbara fel när en uppgift uppdateras automatiskt.

När en ny delversion släpps (till exempel 1.2 till 1.3) använder pipelinen automatiskt den nya versionen. Men om en ny huvudversion släpps (till exempel 2.0) fortsätter pipelinen att använda den huvudversion som du angav tills du redigerar pipelinen och manuellt ändrar till den nya huvudversionen. Loggen innehåller en avisering om att en ny huvudversion är tillgänglig.

Du kan ange vilken delversion som ska användas genom att ange det fullständiga versionsnumret för en uppgift efter @ tecknet (exempel: GoTool@0.3.1). Du kan bara använda uppgiftsversioner som finns för din organisation.

I YAML anger du den huvudversion som använder @ i uppgiftsnamnet. Om du till exempel vill fästa på version 2 av PublishTestResults uppgiften:

steps:
- task: PublishTestResults@2

YAML-pipelines är inte tillgängliga i TFS.

Kontrollalternativ för aktivitet

Varje uppgift erbjuder några kontrollalternativ.

Kontrollalternativ är tillgängliga som nycklar i task avsnittet.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

Kontrollalternativ är tillgängliga som nycklar i task avsnittet.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Kontrollalternativ är tillgängliga som nycklar i task avsnittet.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Kommentar

En viss uppgift eller ett visst jobb kan inte ensidigt avgöra om jobbet/fasen fortsätter. Vad den kan göra är att erbjuda statusen lyckades eller misslyckades, och underordnade aktiviteter/jobb har var och en en villkorsberäkning som gör att de kan bestämma om de ska köras eller inte. Standardvillkoret som i praktiken "körs om vi är i ett lyckat tillstånd".

Fortsätt med fel ändrar detta på ett subtilt sätt. Det "lurar" effektivt alla underordnade steg/jobb att behandla ett resultat som "framgång" i syfte att fatta det beslutet. Eller för att uttrycka det på ett annat sätt, står det "tänk inte på misslyckandet med den här uppgiften när du fattar ett beslut om villkoret för den innehållande strukturen".

Tidsgränsen börjar när aktiviteten börjar köras. Den inkluderar inte den tid då aktiviteten placeras i kö eller väntar på en agent.

Kommentar

Pipelines kan ha en tidsgräns för jobbnivå angiven utöver en tidsgräns på aktivitetsnivå. Om tidsgränsintervallet på jobbnivå förflutit innan steget slutförs avslutas det jobb som körs, även om steget har konfigurerats med ett längre tidsgränsintervall. Mer information finns i Timeouter.

I den här YAML-filen PublishTestResults@2 körs även om föregående steg misslyckas på grund av villkoret succeededOrFailed().

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

Villkor

  • Endast när alla tidigare direkta och indirekta beroenden med samma agentpool har lyckats. Dessa faser eller jobb körs samtidigt om du har olika agentpooler. Detta är standardvärdet om det inte finns något villkor i YAML.

  • Även om ett tidigare beroende har misslyckats, såvida inte körningen avbröts. Använd succeededOrFailed() i YAML för det här villkoret.

  • Även om ett tidigare beroende har misslyckats, även om körningen avbröts. Använd always() i YAML för det här villkoret.

  • Endast när ett tidigare beroende har misslyckats. Använd failed() i YAML för det här villkoret.

Stegmål

Aktiviteter körs i en körningskontext, som antingen är agentvärden eller en container. Ett enskilt steg kan åsidosätta kontexten genom att ange en target. Tillgängliga alternativ är ordet host för att rikta in sig på agentvärden plus alla containrar som definierats i pipelinen. Till exempel:

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

SampleTask Här körs på värden och AnotherTask körs i en container.

Antal återförsök om uppgiften misslyckades

Använd retryCountOnTaskFailure för att ange antalet återförsök om aktiviteten misslyckas. Standardvärdet är noll.

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Kommentar

  • Kräver agentversion 2.194.0 eller senare. Stöds inte för agentlösa uppgifter.
  • Den misslyckade uppgiften försöker igen på några sekunder. Väntetiden mellan varje nytt försök ökar efter varje misslyckat försök.
  • Det finns inget antagande om uppgiftens idempotens. Om aktiviteten har biverkningar (till exempel om den delvis skapade en extern resurs) kan den misslyckas andra gången den körs.
  • Det finns ingen information om antalet återförsök som gjorts tillgängliga för aktiviteten.
  • En varning läggs till i aktivitetsloggarna som anger att den har misslyckats innan den görs om.
  • Alla försök att försöka utföra en aktivitet igen visas i användargränssnittet som en del av samma aktivitetsnod.

YAML-pipelines är inte tillgängliga i TFS.

Miljövariabler

YAML-pipelines stöds i Azure DevOps Server 2019 och senare.

Varje uppgift har en env egenskap som är en lista över strängpar som representerar miljövariabler som mappats till aktivitetsprocessen.

task: AzureCLI@2
displayName: Azure CLI
inputs: # Specific to each task
env:
  ENV_VARIABLE_NAME: value
  ENV_VARIABLE_NAME2: value
  ...

I följande exempel körs script steget, som är en genväg för kommandoradsaktiviteten, följt av motsvarande aktivitetssyntax. Det här exemplet tilldelar ett värde till miljövariabeln, som används för att autentisera AZURE_DEVOPS_EXT_PAT med Azure DevOps CLI.

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'

Installationsprogram för byggverktyg (Azure Pipelines)

Med verktygsinstallationsprogram kan bygg-pipelinen installera och kontrollera dina beroenden. Mer specifikt kan du:

  • Installera ett verktyg eller en körning i farten (även på Microsoft-värdbaserade agenter) precis i tid för din CI-version.

  • Verifiera din app eller ditt bibliotek mot flera versioner av ett beroende, till exempel Node.js.

Du kan till exempel konfigurera bygg-pipelinen för att köra och verifiera din app för flera versioner av Node.js.

Exempel: Testa och verifiera din app på flera versioner av Node.js

Skapa en azure-pipelines.yml fil i projektets baskatalog med följande innehåll.

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.x' # The version we're installing
# Write the installed version to the command line
- script: which node

Skapa en ny bygg-pipeline och kör den. Observera hur bygget körs. Installationsprogrammet för Node.js-verktyget laddar ned den Node.js versionen om den inte redan finns på agenten. Kommandoradsskriptet loggar platsen för den Node.js versionen på disken.

YAML-pipelines är inte tillgängliga i TFS.

Installationsuppgifter för verktyg

En lista över våra verktygsinstallationsuppgifter finns i Verktygsinstallationsuppgifter.

Inaktivera inkorgs- och Marketplace-uppgifter

På sidan organisationsinställningar kan du inaktivera Marketplace-uppgifter, in-box-uppgifter eller både och. Om du inaktiverar Marketplace-uppgifter kan du öka säkerheten för dina pipelines. Om du inaktiverar både in-box- och Marketplace-uppgifter är endast uppgifter som du installerar med tfx tillgängliga.

Hjälp och support