Especificar trabalhos na linha de produção

No caso mais simples, um pipeline tem uma única tarefa. Nesse caso, você não precisa usar explicitamente a job palavra-chave, a menos que esteja usando um modelo. Você pode especificar diretamente as etapas em seu arquivo YAML.

Este ficheiro YAML tem um trabalho que é executado num agente hospedado pela Microsoft e produz saídas .

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

Talvez queiras especificar mais propriedades nessa tarefa. Nesse caso, você pode usar a job palavra-chave.

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

O seu pipeline pode ter múltiplas tarefas. Nesse caso, use a jobs palavra-chave.

jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container
  uses: # Any resources (repos or pools) required by this job that are not already referenced
    repositories: [ string ] # Repository references to Azure Git repositories
    pools: [ string ] # Pool names, typically when using a matrix strategy for the job

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

Para adicionar trabalhos ao seu pipeline de build, edite o pipeline na página Pipelines. Selecione ... para adicionar um trabalho.

Para adicionar trabalhos ao seu pipeline de liberação, edite-o em Pipelines>Releases. Exiba as tarefas do estágio no estágio em que você deseja adicionar seu trabalho. Selecione ... para adicionar um trabalho.

pool:
  name: myPrivateAgents    # your job runs on an agent in this pool
  demands: agent.os -equals Windows_NT    # the agent must have this capability to run the job
steps:
- script: echo hello world

Ou múltiplas exigências:

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

Você pode especificar demandas no pipeline, nos trabalhos ou em ambos. Se especificares demandas no pipeline e num trabalho, a união dos dois conjuntos de demandas é necessária para o sistema selecionar um agente.

A sintaxe completa para especificar um trabalho de servidor é:

jobs:
- job: string
  timeoutInMinutes: number
  cancelTimeoutInMinutes: number
  strategy:
    maxParallel: number
    matrix: { string: { string: string } }

  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Você também pode usar a sintaxe simplificada:

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Adicione um trabalho de servidor no editor, selecionando '...' no canal Pipeline na guia Tarefas de um pipeline. As propriedades do trabalho do servidor são exibidas quando você seleciona o trabalho no editor.

A sintaxe para definir vários trabalhos e suas dependências é:

jobs:
- job: string
  dependsOn: string
  condition: string

Exemplos de trabalhos que são construídos sequencialmente:

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

Exemplos de trabalhos que são criados em paralelo (sem dependências):

jobs:
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux

Exemplo de fan-out:

jobs:
- job: InitialJob
  steps:
  - script: echo hello from initial job
- job: SubsequentA
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent A
- job: SubsequentB
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent B

Exemplo de fan-in:

jobs:
- job: InitialA
  steps:
  - script: echo hello from initial A
- job: InitialB
  steps:
  - script: echo hello from initial B
- job: Subsequent
  dependsOn:
  - InitialA
  - InitialB
  steps:
  - script: echo hello from subsequent

Para adicionar um novo trabalho, selecione '...' no canal do pipeline na guia Tarefas do pipeline. As condições e a ordem de execução de um trabalho são exibidas quando você seleciona o trabalho no editor.

Quando você especifica vários trabalhos em um pipeline de compilação, eles são executados em paralelo por padrão. Você pode especificar a ordem na qual os trabalhos devem ser executados configurando dependências entre trabalhos. Não há suporte para dependências de tarefa em pipelines de lançamento. Vários trabalhos num pipeline de lançamento são executados em sequência.

Por exemplo, o pipeline divide a execução geral do lançamento em tarefas de execução distintas, usando dois trabalhos de agente e um trabalho de servidor .

1. As tarefas no primeiro trabalho da versão são executadas num agente. O agente é liberado após a conclusão do trabalho.

2. O trabalho de servidor contém uma tarefa de Intervenção Manual que é executada nos Pipelines do Azure ou no Servidor de DevOps. O trabalho não requer nem é executado em um agente ou em qualquer servidor de destino especificado. A tarefa de Intervenção Manual exibe a sua mensagem e aguarda uma resposta de "retomar" ou "rejeitar" do utilizador. Neste exemplo, se a tarefa atingir o tempo limite configurado, a tarefa rejeitará automaticamente a implantação. Defina o tempo limite na seção de opções de controle como zero se não quiser que uma resposta automatizada seja gerada.

3. As tarefas no terceiro conjunto de trabalhos são executadas se a publicação for retomada, possivelmente num agente diferente. Se a versão for rejeitada, esse trabalho não será executado e a versão será marcada como falha.

É importante entender algumas das consequências da execução em fases:

• Cada trabalho pode usar agentes diferentes. Não assuma que o estado de um trabalho anterior está disponível durante os trabalhos subsequentes.

• As opções Continuar em Erro e Sempre executar para tarefas em cada trabalho não têm qualquer efeito nas tarefas em trabalhos subsequentes. Por exemplo, definir Sempre executar numa tarefa no final da primeira tarefa não garante que as tarefas em trabalhos subsequentes sejam executadas.

Exemplo para executar um trabalho com base no status de execução de um trabalho anterior:

jobs:
- job: A
  steps:
  - script: exit 1

- job: B
  dependsOn: A
  condition: failed()
  steps:
  - script: echo this will run when A fails

- job: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')
  steps:
  - script: echo this will run when B runs and succeeds

Exemplo de utilização de uma condição personalizada:

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))
  steps:
  - script: echo this only runs for master

Você pode especificar que um trabalho seja executado com base no valor de uma variável de saída definida em um trabalho anterior. Nesse caso, você só pode usar variáveis definidas em trabalhos diretamente dependentes:

jobs:
- job: A
  steps:
  - script: "echo '##vso[task.setvariable variable=skipsubsequent;isOutput=true]false'"
    name: printvar

- job: B
  condition: and(succeeded(), ne(dependencies.A.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  steps:
  - script: echo hello from B

Use a opção Executar este trabalho em um agente ou trabalho de servidor para executar as tarefas somente quando condições específicas forem atendidas. Selecione uma condição predefinida ou selecione "personalizado" e insira uma expressão que seja avaliada como verdadeiro ou falso. Expressões encadeadas podem ser usadas, e as expressões podem aceder a variáveis disponíveis no pipeline de lançamento.

O timeoutInMinutes permite que um limite seja definido para o tempo de execução do trabalho. Quando não especificado, o padrão é 60 minutos. Quando 0 é especificado, o limite máximo é usado.

O cancelTimeoutInMinutes permite que um limite seja definido para o tempo de cancelamento do trabalho quando a tarefa de implantação é definida para continuar em execução se uma tarefa anterior falhar. Quando não especificado, o padrão é 5 minutos. O valor deve estar no intervalo de 1 a 35790 minutos.

jobs:
- job: Test
  timeoutInMinutes: 10 # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them

Selecione o trabalho e, em seguida, especifique o valor de tempo limite.

Na guia Opções, você pode especificar valores padrão para todos os trabalhos no pipeline. Se você especificar um valor diferente de zero para o tempo limite do trabalho, ele substituirá qualquer valor especificado nas opções de pipeline. Se você especificar um valor zero, o valor de tempo limite das opções de pipeline será usado. Se o valor do pipeline também estiver definido como zero, não haverá tempo limite.

A matrix estratégia permite que um trabalho seja despachado várias vezes, com diferentes conjuntos de variáveis. A maxParallel tag restringe a quantidade de paralelismo. O trabalho a seguir é enviado três vezes com os valores de Localização e Navegador definidos conforme especificado. No entanto, apenas dois trabalhos são executados ao mesmo tempo.

jobs:
- job: Test
  strategy:
    maxParallel: 2
    matrix: 
      US_IE:
        Location: US
        Browser: IE
      US_Chrome:
        Location: US
        Browser: Chrome
      Europe_Chrome:
        Location: Europe
        Browser: Chrome

Também é possível usar variáveis de saída para gerar uma matriz. Esse método pode ser útil se você precisar gerar a matriz usando um script.

matrix aceita uma expressão de tempo de execução contendo um objeto JSON stringified. Esse objeto JSON, quando expandido, deve corresponder à sintaxe de matriz. No exemplo a seguir, codificamos a cadeia de caracteres JSON, mas você pode gerá-la com uma linguagem de script ou um programa de linha de comando.

jobs:
- job: generator
  steps:
  - bash: echo "##vso[task.setVariable variable=legs;isOutput=true]{'a':{'myvar':'A'}, 'b':{'myvar':'B'}}"
    name: mtrx
  # This expands to the matrix
  #   a:
  #     myvar: A
  #   b:
  #     myvar: B
- job: runner
  dependsOn: generator
  strategy:
    matrix: $[ dependencies.generator.outputs['mtrx.legs'] ]
  steps:
  - script: echo $(myvar) # echos A or B depending on which leg is running

Para executar vários trabalhos usando a opção de multiconfiguração, identifique uma variável chamada multiplicador e especifique uma lista de valores para esse multiplicador. Um trabalho separado é executado para cada valor na lista. Para usar multiplicadores para compilação ou implementação, deve-se:

• Defina uma ou mais variáveis no separador Variáveis do pipeline ou num grupo de variáveis. Cada variável, conhecida neste contexto como uma variável multiplicadora , deve ser definida como uma lista delimitada por vírgulas dos valores que você deseja passar individualmente para os agentes.

• Insira o nome da variável multiplicadora, sem os $ e parênteses, como o valor do parâmetro Multipliers . Não há suporte para o uso de uma variável secreta como variável multiplicadora.

• Se você quiser executar o trabalho para mais de uma variável multiplicadora, insira os nomes das variáveis como uma lista delimitada por vírgulas - omitindo os $ e parênteses para cada uma.

• Se você quiser limitar o número de agentes usados durante a implantação a um número menor do que o configurado para sua assinatura, insira esse valor como o Número máximo de agentes parâmetro.

Por exemplo, você pode definir duas variáveis chamadas Localização e Navegador da seguinte maneira:

• Localização = US,Europe
• Navegador = IE,Chrome,Edge,Firefox

A configuração a seguir executa a implantação oito vezes usando um máximo de quatro agentes ao mesmo tempo:

• Multiplicadores = Location,Browser
• Número máximo de agentes = 4

Com a multiconfiguração, você pode executar vários trabalhos, cada um com um valor diferente para uma ou mais variáveis (multiplicadores). Se você quiser executar o mesmo trabalho em vários agentes, poderá usar a opção de paralelismo de vários agentes . O exemplo anterior de fatiamento de teste pode ser realizado pela opção multi-agente.

A parallel estratégia permite que um trabalho seja duplicado muitas vezes. Variáveis System.JobPositionInPhase e System.TotalJobsInPhase são adicionadas a cada trabalho. As variáveis podem ser usadas nos seus scripts para dividir o trabalho entre as tarefas. Consulte Execução paralela e múltipla usando trabalhos de agentes.

O trabalho a seguir é despachado cinco vezes com os valores de System.JobPositionInPhase e System.TotalJobsInPhase definidos de forma adequada.

jobs:
- job: Test
  strategy:
    parallel: 5

Especifique a opção multi-agente num trabalho de agente para aplicar o fatiamento. O trabalho é enviado tantas vezes quantos forem o número de agentes que especificar, e as variáveis System.JobPositionInPhase e System.TotalJobsInPhase são definidas automaticamente em cada trabalho.

Aqui está um exemplo de como definir variáveis em um trabalho e usá-las dentro de tarefas.

variables:
  mySimpleVar: simple var value
  "my.dotted.var": dotted var value
  "my var with spaces": var with spaces value

steps:
- script: echo Input macro = $(mySimpleVar). Env var = %MYSIMPLEVAR%
  condition: eq(variables['agent.os'], 'Windows_NT')
- script: echo Input macro = $(mySimpleVar). Env var = $MYSIMPLEVAR
  condition: in(variables['agent.os'], 'Darwin', 'Linux')
- bash: echo Input macro = $(my.dotted.var). Env var = $MY_DOTTED_VAR
- powershell: Write-Host "Input macro = $(my var with spaces). Env var = $env:MY_VAR_WITH_SPACES"

As variáveis de trabalho ainda não são suportadas no editor da Web.

Os $(Build.ArtifactStagingDirectory) e $(Common.TestResultsDirectory) são sempre excluídos e recriados de novo antes de cada compilação.

Quando um pipeline é executado num agente auto-hospedado, por padrão, nenhum dos subdiretórios, além de $(Build.ArtifactStagingDirectory) e $(Common.TestResultsDirectory), é limpo entre duas execuções consecutivas. Como resultado, é possível fazer construções e implementações incrementais, caso as tarefas sejam implementadas para as utilizar. Você pode substituir esse comportamento usando a configuração workspace no trabalho.

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Quando você especifica uma das clean opções, elas são interpretadas da seguinte forma:

• outputs: Excluir Build.BinariesDirectory antes de executar um novo trabalho.
• resources: Excluir Build.SourcesDirectory antes de executar um novo trabalho.
• all: Exclua o diretório Pipeline.Workspace inteiro antes de executar uma nova tarefa.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Além de limpar o espaço de trabalho, é possível configurar a limpeza ajustando a definição Limpar na interface do utilizador das configurações do pipeline. Quando a definição Limpar é true, que também é o seu valor padrão, é equivalente a especificar clean: true para cada etapa de checkout do seu pipeline. Ao especificar clean: true, você executa git clean -ffdx seguido por git reset --hard HEAD antes da busca do git. Para configurar a definição Limpar:

1. Edite seu pipeline, escolha ..., e selecione Triggers.

   

2. Selecione YAML, Obter fontes e configure a opção Limpar desejada. O padrão é true.

   

Quando você executa um pipeline em um agente auto-hospedado, por padrão, nenhum dos subdiretórios é limpo entre duas execuções consecutivas. Como resultado, você pode executar compilações e implantações incrementais, se as tarefas forem implementadas para fazer isso. No entanto, você pode substituir esse comportamento usando a Clean build opção na Get sources tarefa. As opções variam dependendo do tipo de repositório que você usa.

• GitHub
• Azure Repos Git
• CVF

# test and upload my code as an artifact named Website
jobs:
- job: Build
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm test
  - task: PublishPipelineArtifact@1
    inputs:
      artifactName: Website
      targetPath: '$(System.DefaultWorkingDirectory)'

# download the artifact and deploy it only if the build job succeeded
- job: Deploy
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - checkout: none #skip checking out the default repository resource
  - task: DownloadPipelineArtifact@2
    displayName: 'Download Pipeline Artifact'
    inputs:
      artifactName: Website
      targetPath: '$(Pipeline.Workspace)'
  dependsOn: Build
  condition: succeeded()

Num pipeline de lançamento, pode-se optar por ignorar o download de artefatos durante a execução da tarefa. Use essa opção se quiser implementar sua própria lógica personalizada para baixar artefatos usando tarefas ou se as tarefas em um trabalho específico não dependerem dos artefatos.

Como alternativa, pode-se optar por baixar artefatos específicos durante a execução do trabalho numa release. Use esta opção se as tarefas em um trabalho específico dependerem apenas de artefatos específicos.

O token OAuth está sempre disponível para pipelines YAML. Ele deve ser explicitamente mapeado na tarefa ou etapa usando env. Eis um exemplo:

steps:
- powershell: |
    $url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=4.1-preview"
    Write-Host "URL: $url"
    $pipeline = Invoke-RestMethod -Uri $url -Headers @{
      Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
    }
    Write-Host "Pipeline = $($pipeline | ConvertTo-Json -Depth 100)"
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

Selecione a opção Permitir que scripts acessem o token OAuth nas opções de controle para o trabalho. O token está disponível como a variável SYSTEM_ACCESSTOKENde ambiente .