Läs på engelska

Dela via

Aktivitetstyper och användning

  • Artikel

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

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 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:

YAML 
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 myExtensionId på en uppgift 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:

YAML 
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.

YAML 
- 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.

YAML 
- 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.

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

YAML 
- 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.

Anteckning

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.

Anteckning

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().

YAML 
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 lyckas. Om du har olika agentpooler körs dessa faser eller jobb samtidigt. Det här villkoret är standard om inget villkor har angetts i YAML.

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

  • Även om ett tidigare beroende misslyckas och även om körningen avbryts. Använd always() i YAML för det här villkoret.

  • Endast när ett tidigare beroende misslyckas. 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:

YAML 
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 återförsök. Mer information om aktivitetsegenskaper finns i steps.task i YAML-schemat.

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

Anteckning

  • Kräver agentversion 2.194.0 eller senare. På Azure DevOps Server 2022 stöds inte återförsök för agentlösa uppgifter. Mer information finns i Azure DevOps-tjänstuppdatering 16 november 2021 – Automatiska återförsök för en aktivitet och Azure DevOps-tjänstuppdatering 14 juni 2025 – Återförsök för serveruppgifter.
  • Det maximala antalet återförsök som tillåts är 10.
  • Väntetiden mellan varje återförsök ökar efter varje misslyckat försök, efter en exponentiell backoff-strategi. Det första återförsöket sker efter 1 sekund, det andra återförsöket efter 4 sekunder och det tionde återförsöket efter 100 sekunder.
  • 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

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

yml 
- 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.

yml 
# 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'
yml 
- task: Bash@3
  inputs:
     targetType: # 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 Bash@3, följt av motsvarande aktivitetssyntax. I det här exemplet tilldelas miljövariabeln ett värde ENV_VARIABLE_NAME och värdet upprepas.

yml 
# Using the script shortcut syntax
- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

# Using the task syntax
- task: Bash@2
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

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.

YAML 
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

Obs! Författaren skapade den här artikeln med hjälp av AI. Läs mer