Bagikan melalui


Menentukan pekerjaan di alur Anda

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Anda dapat mengatur alur Anda ke dalam pekerjaan. Setiap alur memiliki setidaknya satu pekerjaan. Pekerjaan adalah serangkaian langkah yang berjalan secara berurutan sebagai unit. Dengan kata lain, pekerjaan adalah unit kerja terkecil yang dapat dijadwalkan untuk dijalankan.

Untuk mempelajari tentang konsep dan komponen utama yang membentuk alur, lihat Konsep utama untuk pengguna Azure Pipelines baru.

Azure Pipelines tidak mendukung prioritas pekerjaan untuk alur YAML. Untuk mengontrol kapan pekerjaan berjalan, Anda dapat menentukan kondisi dan dependensi.

Menentukan satu pekerjaan

Dalam kasus paling sederhana, alur memiliki satu pekerjaan. Dalam hal ini, Anda tidak perlu secara eksplisit menggunakan job kata kunci kecuali Anda menggunakan templat. Anda dapat langsung menentukan langkah-langkah dalam file YAML Anda.

File YAML ini memiliki pekerjaan yang berjalan pada agen dan output Hello worldyang dihosting Microsoft.

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

Anda mungkin ingin menentukan lebih banyak properti pada pekerjaan tersebut. Dalam hal ini, Anda dapat menggunakan job kata kunci.

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

Alur Anda bisa memiliki beberapa pekerjaan. Dalam hal ini, gunakan jobs kata kunci.

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

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

Alur Anda mungkin memiliki beberapa tahap, masing-masing dengan beberapa pekerjaan. Dalam hal ini, gunakan stages kata kunci.

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

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

Sintaks lengkap untuk menentukan pekerjaan adalah:

- 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

Sintaks lengkap untuk menentukan pekerjaan adalah:

- 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

Jika niat utama pekerjaan Anda adalah untuk menyebarkan aplikasi Anda (dibandingkan dengan membangun atau menguji aplikasi Anda), maka Anda dapat menggunakan jenis pekerjaan khusus yang disebut pekerjaan penyebaran.

Sintaks untuk pekerjaan penyebaran adalah:

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

Meskipun Anda dapat menambahkan langkah-langkah untuk tugas penyebaran dalam job, kami sarankan Anda menggunakan pekerjaan penyebaran. Pekerjaan penyebaran memiliki beberapa manfaat. Misalnya, Anda dapat menyebarkan ke lingkungan, yang mencakup manfaat seperti dapat melihat riwayat apa yang telah Anda sebarkan.

Jenis pekerjaan

Pekerjaan dapat dari berbagai jenis, tergantung di mana mereka berjalan.

  • Pekerjaan kumpulan agen berjalan pada agen di kumpulan agen.
  • Pekerjaan server berjalan pada Azure DevOps Server.
  • Pekerjaan kontainer dijalankan dalam kontainer pada agen di kumpulan agen. Untuk informasi selengkapnya tentang memilih kontainer, lihat Menentukan pekerjaan kontainer.
  • Pekerjaan kumpulan agen berjalan pada agen di kumpulan agen.
  • Pekerjaan server berjalan pada Azure DevOps Server.

Pekerjaan kumpulan agen

Ini adalah jenis pekerjaan yang paling umum dan dijalankan pada agen di kumpulan agen.

  • Saat menggunakan agen yang dihosting Microsoft, setiap pekerjaan dalam alur mendapatkan agen baru.
  • Gunakan tuntutan dengan agen yang dihost sendiri untuk menentukan kemampuan apa yang harus dimiliki agen untuk menjalankan pekerjaan Anda. Anda mungkin mendapatkan agen yang sama untuk pekerjaan berturut-turut, tergantung pada apakah ada lebih dari satu agen di kumpulan agen Anda yang sesuai dengan permintaan alur Anda. Jika hanya ada satu agen di kumpulan Anda yang cocok dengan permintaan alur, alur menunggu hingga agen ini tersedia.

Catatan

Tuntutan dan kemampuan dirancang untuk digunakan dengan agen yang dihost sendiri sehingga pekerjaan dapat dicocokkan dengan agen yang memenuhi persyaratan pekerjaan. Saat menggunakan agen yang dihosting Microsoft, Anda memilih gambar untuk agen yang cocok dengan persyaratan pekerjaan, jadi meskipun dimungkinkan untuk menambahkan kemampuan ke agen yang dihosting Microsoft, Anda tidak perlu menggunakan kemampuan dengan agen yang dihosting Microsoft.

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

Atau beberapa tuntutan:

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

Pelajari selengkapnya tentang kemampuan agen.

Pekerjaan server

Tugas dalam pekerjaan server diorkestrasi oleh dan dijalankan di server (Azure Pipelines atau TFS). Pekerjaan server tidak memerlukan agen atau komputer target apa pun. Hanya beberapa tugas yang didukung dalam pekerjaan server sekarang. Waktu maksimum untuk pekerjaan server adalah 30 hari.

Tugas yang didukung pekerjaan tanpa agen

Saat ini, hanya tugas berikut yang didukung di luar kotak untuk pekerjaan tanpa agen:

Karena tugas dapat diperluas, Anda dapat menambahkan lebih banyak tugas tanpa agen dengan menggunakan ekstensi. Batas waktu default untuk pekerjaan tanpa agen adalah 60 menit.

Sintaks lengkap untuk menentukan pekerjaan server adalah:

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

Anda juga dapat menggunakan sintaks yang disederhanakan:

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

Dependensi

Saat Anda menentukan beberapa pekerjaan dalam satu tahap, Anda dapat menentukan dependensi di antaranya. Alur harus berisi setidaknya satu pekerjaan tanpa dependensi. Secara default, pekerjaan alur YAML Azure DevOps berjalan secara paralel kecuali dependsOn nilainya diatur.

Catatan

Setiap agen hanya dapat menjalankan satu pekerjaan pada satu waktu. Untuk menjalankan beberapa pekerjaan secara paralel, Anda harus mengonfigurasi beberapa agen. Anda juga memerlukan pekerjaan paralel yang memadai.

Sintaks untuk menentukan beberapa pekerjaan dan dependensinya adalah:

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

Contoh pekerjaan yang dibangun secara berurutan:

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

Contoh pekerjaan yang dibangun secara paralel (tanpa dependensi):

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

Contoh 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

Contoh 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

Kondisi

Anda dapat menentukan kondisi di mana setiap pekerjaan berjalan. Secara default, pekerjaan berjalan jika tidak bergantung pada pekerjaan lain, atau jika semua pekerjaan yang bergantung pada pekerjaan telah selesai dan berhasil. Anda dapat menyesuaikan perilaku ini dengan memaksa pekerjaan berjalan meskipun pekerjaan sebelumnya gagal atau dengan menentukan kondisi kustom.

Contoh untuk menjalankan pekerjaan berdasarkan status menjalankan pekerjaan sebelumnya:

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

Contoh penggunaan kondisi kustom:

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

Anda dapat menentukan bahwa pekerjaan berjalan berdasarkan nilai variabel output yang ditetapkan dalam pekerjaan sebelumnya. Dalam hal ini, Anda hanya dapat menggunakan variabel yang diatur dalam pekerjaan dependen langsung:

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

Waktu habis

Untuk menghindari mengambil sumber daya ketika pekerjaan Anda tidak responsif atau menunggu terlalu lama, ada baiknya menetapkan batasan berapa lama pekerjaan Anda diizinkan untuk dijalankan. Gunakan pengaturan batas waktu pekerjaan untuk menentukan batas dalam menit untuk menjalankan pekerjaan. Mengatur nilai ke nol berarti pekerjaan dapat berjalan:

  • Selamanya pada agen yang dihost sendiri
  • Selama 360 menit (6 jam) pada agen yang dihosting Microsoft dengan proyek publik dan repositori publik
  • Selama 60 menit pada agen yang dihosting Microsoft dengan proyek privat atau repositori privat (kecuali kapasitas tambahan dibayarkan)

Periode batas waktu dimulai ketika pekerjaan mulai berjalan. Ini tidak termasuk waktu pekerjaan diantrekan atau sedang menunggu agen.

memungkinkan timeoutInMinutes batas untuk diatur untuk waktu eksekusi pekerjaan. Ketika tidak ditentukan, defaultnya adalah 60 menit. Ketika 0 ditentukan, batas maksimum digunakan (dijelaskan di atas).

cancelTimeoutInMinutes memungkinkan batas untuk diatur untuk waktu pembatalan pekerjaan ketika tugas penyebaran diatur untuk terus berjalan jika tugas sebelumnya gagal. Ketika tidak ditentukan, defaultnya adalah 5 menit. Nilai harus berkisar antara 1 hingga 35790 menit.

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

Batas waktu memiliki tingkat prioritas berikut.

  1. Pada agen yang dihosting Microsoft, pekerjaan dibatasi dalam berapa lama mereka dapat berjalan berdasarkan jenis proyek dan apakah mereka dijalankan menggunakan pekerjaan paralel berbayar. Ketika interval batas waktu pekerjaan yang dihosting Microsoft berlalu, pekerjaan dihentikan. Pada agen yang dihosting Microsoft, pekerjaan tidak dapat berjalan lebih lama dari interval ini, terlepas dari batas waktu tingkat pekerjaan apa pun yang ditentukan dalam pekerjaan.
  2. Batas waktu yang dikonfigurasi pada tingkat pekerjaan menentukan durasi maksimum untuk pekerjaan yang akan dijalankan. Ketika interval batas waktu tingkat pekerjaan berlalu, pekerjaan dihentikan. Jika pekerjaan dijalankan pada agen yang dihosting Microsoft, mengatur batas waktu tingkat pekerjaan ke interval yang lebih besar dari batas waktu tingkat pekerjaan bawaan yang dihosting Microsoft tidak berpengaruh dan batas waktu pekerjaan yang dihosting Microsoft digunakan.
  3. Anda juga dapat mengatur batas waktu untuk setiap tugas satu per satu - lihat opsi kontrol tugas. Jika interval batas waktu tingkat pekerjaan berlalu sebelum tugas selesai, pekerjaan yang sedang berjalan dihentikan, bahkan jika tugas dikonfigurasi dengan interval batas waktu yang lebih lama.

Konfigurasi multi-pekerjaan

Dari satu pekerjaan yang Anda tulis, Anda dapat menjalankan beberapa pekerjaan di beberapa agen secara paralel. Beberapa contohnya termasuk:

  • Build multi-konfigurasi: Anda dapat membangun beberapa konfigurasi secara paralel. Misalnya, Anda dapat membangun aplikasi Visual C++ untuk konfigurasi dan debug release di platform dan .x86 x64 Untuk informasi selengkapnya, lihat Visual Studio Build - beberapa konfigurasi untuk beberapa platform.

  • Penyebaran multi-konfigurasi: Anda dapat menjalankan beberapa penyebaran secara paralel, misalnya, ke wilayah geografis yang berbeda.

  • Pengujian multi-konfigurasi: Anda dapat menjalankan pengujian beberapa konfigurasi secara paralel.

  • Multi-konfigurasi akan selalu menghasilkan setidaknya satu pekerjaan, bahkan jika variabel multi-konfigurasi kosong.

Strategi ini matrix memungkinkan pekerjaan dikirim beberapa kali, dengan set variabel yang berbeda. Tag maxParallel membatasi jumlah paralelisme. Pekerjaan berikut dikirim tiga kali dengan nilai Lokasi dan Browser yang ditetapkan sebagaimana ditentukan. Namun, hanya dua pekerjaan yang berjalan pada saat yang sama.

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

Catatan

Nama konfigurasi matriks (seperti US_IE di atas) hanya boleh berisi huruf alfabet Latin dasar (A-Z, a-z), angka, dan garis bawah (_). Nama kolom harus diawali dengan huruf. Selain itu, mereka harus 100 karakter atau kurang.

Anda juga dapat menggunakan variabel output untuk menghasilkan matriks . Ini bisa berguna jika Anda perlu membuat matriks menggunakan skrip.

matrix menerima ekspresi runtime yang berisi objek JSON yang di string. Objek JSON itu, ketika diperluas, harus cocok dengan sintaks matriks. Dalam contoh di bawah ini, kami telah mengkodekan string JSON secara permanen, tetapi dapat dihasilkan oleh bahasa skrip atau program baris perintah.

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

Membelah

Pekerjaan agen dapat digunakan untuk menjalankan serangkaian pengujian secara paralel. Misalnya, Anda dapat menjalankan rangkaian besar 1000 pengujian pada satu agen. Atau, Anda dapat menggunakan dua agen dan menjalankan 500 pengujian pada masing-masing secara paralel.

Untuk menerapkan pemotongan, tugas dalam pekerjaan harus cukup cerdas untuk memahami irisan miliknya.

Tugas Uji Visual Studio adalah salah satu tugas seperti itu yang mendukung pemotongan pengujian. Jika Anda menginstal beberapa agen, Anda dapat menentukan bagaimana tugas Pengujian Visual Studio berjalan secara paralel pada agen ini.

Strategi ini parallel memungkinkan pekerjaan diduplikasi berkali-kali. System.JobPositionInPhase Variabel dan System.TotalJobsInPhase ditambahkan ke setiap pekerjaan. Variabel kemudian dapat digunakan dalam skrip Anda untuk membagi pekerjaan di antara pekerjaan. Lihat Paralel dan beberapa eksekusi menggunakan pekerjaan agen.

Pekerjaan berikut dikirim lima kali dengan nilai System.JobPositionInPhase dan System.TotalJobsInPhase diatur dengan tepat.

jobs:
- job: Test
  strategy:
    parallel: 5

Variabel pekerjaan

Jika Anda menggunakan YAML, variabel dapat ditentukan pada pekerjaan. Variabel dapat diteruskan ke input tugas menggunakan sintaks makro $(variableName), atau diakses dalam skrip menggunakan variabel tahap.

Berikut adalah contoh menentukan variabel dalam pekerjaan dan menggunakannya dalam tugas.

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"

Untuk informasi tentang menggunakan kondisi, lihat Menentukan kondisi.

Ruang kerja

Saat Anda menjalankan pekerjaan kumpulan agen, ia membuat ruang kerja pada agen. Ruang kerja adalah direktori di mana ia mengunduh sumber, menjalankan langkah-langkah, dan menghasilkan output. Direktori ruang kerja dapat direferensikan dalam pekerjaan Anda menggunakan Pipeline.Workspace variabel. Di bawah ini, berbagai subdirektori dibuat:

  • Build.SourcesDirectory adalah tempat tugas mengunduh kode sumber aplikasi.
  • Build.ArtifactStagingDirectory adalah tempat tugas mengunduh artefak yang diperlukan untuk alur atau mengunggah artefak sebelum diterbitkan.
  • Build.BinariesDirectory adalah tempat tugas menulis output mereka.
  • Common.TestResultsDirectory adalah tempat tugas mengunggah hasil pengujian mereka.

$(Build.ArtifactStagingDirectory) dan $(Common.TestResultsDirectory) selalu dihapus dan dibuat ulang sebelum setiap build.

Saat Anda menjalankan alur pada agen yang dihost sendiri, secara default, tidak ada subdirektori selain $(Build.ArtifactStagingDirectory) dan $(Common.TestResultsDirectory) dibersihkan di antara dua eksekusi berturut-turut. Akibatnya, Anda dapat melakukan build dan penyebaran bertahap, asalkan tugas diimplementasikan untuk memanfaatkannya. Anda dapat mengambil alih perilaku ini menggunakan workspace pengaturan pada pekerjaan.

Penting

Opsi bersih ruang kerja hanya berlaku untuk agen yang dihost sendiri. Pekerjaan selalu dijalankan pada agen baru dengan agen yang dihosting Microsoft.

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

Saat Anda menentukan salah satu opsi, opsi tersebut clean ditafsirkan sebagai berikut:

  • outputs: Hapus Build.BinariesDirectory sebelum menjalankan pekerjaan baru.
  • resources: Hapus Build.SourcesDirectory sebelum menjalankan pekerjaan baru.
  • all: Hapus seluruh Pipeline.Workspace direktori sebelum menjalankan pekerjaan baru.
  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Catatan

Tergantung pada kemampuan agen dan permintaan alur Anda, setiap pekerjaan dapat dirutekan ke agen yang berbeda di kumpulan yang dihost sendiri. Akibatnya, Anda mungkin mendapatkan agen baru untuk eksekusi alur berikutnya (atau tahap atau pekerjaan dalam alur yang sama), jadi tidak membersihkan bukanlah jaminan bahwa eksekusi, pekerjaan, atau tahap berikutnya akan dapat mengakses output dari eksekusi, pekerjaan, atau tahap sebelumnya. Anda dapat mengonfigurasi kemampuan agen dan tuntutan alur untuk menentukan agen mana yang digunakan untuk menjalankan pekerjaan alur, tetapi kecuali hanya ada satu agen di kumpulan yang memenuhi tuntutan, tidak ada jaminan bahwa pekerjaan berikutnya akan menggunakan agen yang sama dengan pekerjaan sebelumnya. Untuk informasi selengkapnya, lihat Menentukan permintaan.

Selain membersihkan ruang kerja, Anda juga dapat mengonfigurasi pembersihan dengan mengonfigurasi pengaturan Bersihkan di antarmuka pengguna pengaturan alur. Saat pengaturan Bersihkan benar, yang juga merupakan nilai defaultnya, setara dengan menentukan clean: true untuk setiap langkah checkout di alur Anda. Saat Anda menentukan clean: true, Anda akan berjalan git clean -ffdx diikuti oleh git reset --hard HEAD sebelum pengambilan git. Untuk mengonfigurasi pengaturan Bersih :

  1. Edit alur Anda, pilih ..., dan pilih Pemicu.

    Edit pemicu.

  2. Pilih YAML, Dapatkan sumber, dan konfigurasikan pengaturan Bersih yang Anda inginkan. Defaultnya adalah true

    Pengaturan bersih.

Unduhan artefak

Contoh file YAML ini menerbitkan artefak WebSite lalu mengunduh artefak ke $(Pipeline.Workspace). Pekerjaan Sebarkan hanya berjalan jika pekerjaan Build berhasil.

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

# 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: DownloadBuildArtifacts@0
    displayName: 'Download Build Artifacts'
    inputs:
      artifactName: WebSite
      downloadPath: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

Untuk informasi tentang menggunakan dependsOn dan kondisi, lihat Menentukan kondisi.

Akses ke token OAuth

Anda dapat mengizinkan skrip yang berjalan dalam pekerjaan untuk mengakses token keamanan Azure Pipelines atau TFS OAuth saat ini. Token dapat digunakan untuk mengautentikasi ke AZURE Pipelines REST API.

Token OAuth selalu tersedia untuk alur YAML. Ini harus secara eksplisit dipetakan ke dalam tugas atau langkah menggunakan env. Berikut contohnya:

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)

Selanjutnya