Bagikan melalui

Sumber daya dalam alur YAML

  • Artikel

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

Artikel ini membahas sumber daya untuk alur YAML. Sumber daya adalah apa pun yang digunakan oleh alur yang ada di luar alur. Setelah menentukan sumber daya, Anda dapat menggunakannya di mana saja di alur Anda.

Sumber daya menyediakan keterlacakan penuh untuk layanan yang digunakan alur Anda, termasuk versi, artefak, penerapan terkait, dan item kerja. Anda dapat sepenuhnya mengotomatiskan alur kerja DevOps anda dengan berlangganan untuk memicu peristiwa pada sumber daya Anda.

Skema sumber daya

Sumber daya dalam YAML mewakili sumber alur, build, repositori, kontainer, paket, dan webhook. Untuk informasi skema lengkap, lihat definisi sumber daya dalam referensi skema YAML untuk Azure Pipelines.

Saat sumber daya memicu alur, variabel berikut diatur:

resources.triggeringAlias
resources.triggeringCategory

Variabel Build.Reason harus agar ResourceTrigger nilai-nilai ini diatur. Nilai kosong jika sumber daya tidak memicu eksekusi alur.

Definisi sumber daya alur

Jika Anda memiliki alur yang menghasilkan artefak, Anda dapat menggunakan artefak dengan menentukan pipelines sumber daya. Hanya Azure Pipelines yang dapat menggunakan pipelines sumber daya. Anda dapat mengatur pemicu untuk alur kerja penyebaran berkelanjutan (CD) Anda pada sumber daya alur.

Dalam definisi sumber daya Anda, pipeline adalah nilai unik yang dapat Anda gunakan untuk mereferensikan sumber daya alur nanti di alur Anda. source adalah nama alur yang menghasilkan artefak alur. Untuk informasi skema lengkap, lihat definisi resources.pipelines.pipeline.

Anda menggunakan label yang ditentukan oleh pipeline untuk mereferensikan sumber daya alur dari bagian lain dari alur Anda, seperti saat menggunakan variabel sumber daya alur atau mengunduh artefak. Untuk cara alternatif untuk mengunduh artefak alur, lihat Mengunduh artefak.

Penting

Saat Anda menentukan pemicu sumber daya alur:

  • pipeline Jika sumber daya berasal dari repositori yang sama dengan alur saat ini, atau self, pemicu mengikuti cabang yang sama dan penerapan tempat peristiwa dinaikkan.
  • Jika sumber daya alur berasal dari repositori yang berbeda, alur saat ini memicu pada cabang pipeline default repositori sumber daya.

Contoh definisi sumber daya alur

Contoh berikut menggunakan artefak dari alur dalam proyek yang sama.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

Untuk menggunakan alur dari proyek lain, Anda menyertakan nama proyek dan nama sumber. Contoh berikut menggunakan branch untuk mengatasi versi default saat alur dipicu secara manual atau terjadwal. Input cabang tidak dapat memiliki kartubebas.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

Contoh berikut menunjukkan sumber daya alur dengan pemicu sederhana.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger: true

Contoh berikut menunjukkan sumber daya trigger alur dengan kondisi cabang.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

Contoh berikut menggunakan stages filter untuk mengevaluasi kondisi pemicu untuk alur CD. Tahapan menggunakan AND operator. Setelah berhasil menyelesaikan semua tahap yang disediakan, alur CD memicu.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

Contoh berikut menggunakan tags filter untuk evaluasi versi default dan untuk pemicu. Tag menggunakan AND operator.

tags diatur pada integrasi berkelanjutan (CI) atau alur CD. Tag ini berbeda dari tag yang ditetapkan pada cabang di repositori Git.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

Evaluasi versi artefak alur

Versi artefak alur sumber daya tergantung pada cara alur memicu.

Pemicu manual atau terjadwal

Jika eksekusi alur dipicu atau dijadwalkan secara manual, nilai versionproperti , , branchdan tags menentukan versi artefak. Input branch tidak dapat memiliki kartubebas. Properti tags menggunakan AND operator .

Properti yang ditentukan Versi artefak
version Artefak dari build yang memiliki nomor eksekusi yang ditentukan
branch Artefak dari build terbaru yang dilakukan pada cabang yang ditentukan
tags daftar Artefak dari build terbaru yang memiliki semua tag yang ditentukan
branch dan tags daftar Artefak dari build terbaru yang dilakukan pada cabang yang ditentukan yang memiliki semua tag yang ditentukan
Tidak Artefak dari build terbaru di semua cabang

Definisi sumber daya berikut pipeline menggunakan branch properti dan tags untuk mengevaluasi versi default saat alur dipicu secara manual atau terjadwal. Saat Anda secara manual memicu alur untuk dijalankan, MyCIAlias versi artefak alur adalah build terbaru yang dilakukan pada main cabang yang memiliki Production tag dan PrepProduction .

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

Pemicu penyelesaian alur sumber daya

Ketika alur memicu karena salah satu alur sumber dayanya selesai, versi artefak adalah versi alur pemicu. versionNilai properti , branch, dan tags diabaikan.

Pemicu yang ditentukan Hasil
branches Eksekusi alur baru memicu setiap kali alur sumber daya berhasil menyelesaikan eksekusi di salah include satu cabang.
tags Eksekusi alur baru memicu setiap kali alur sumber daya berhasil menyelesaikan eksekusi yang ditandai dengan semua tag yang ditentukan.
stages Eksekusi alur baru memicu setiap kali alur sumber daya berhasil menjalankan stages.
branches, tags, dan stages Eksekusi alur baru memicu setiap kali eksekusi alur sumber daya memenuhi semua kondisi cabang, tag, dan tahapan.
trigger: true Eksekusi alur baru memicu setiap kali alur sumber daya berhasil menyelesaikan eksekusi.
Tidak ada Tidak ada pemicu eksekusi alur baru saat alur sumber daya berhasil menyelesaikan eksekusi.

Alur berikut berjalan setiap kali SmartHotel-CI alur sumber daya:

  • Berjalan di salah releases satu cabang atau di main cabang
  • Ditandai dengan dan VerifiedSigned
  • Menyelesaikan tahapan Production dan PreProduction
resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Unduhan artefak alur

Langkah ini download mengunduh artefak yang terkait dengan eksekusi saat ini atau dengan sumber daya alur lain.

Semua artefak dari alur saat ini dan semua sumber dayanya pipeline secara otomatis diunduh dan tersedia di awal setiap pekerjaan penyebaran. Anda dapat mengambil alih perilaku ini dengan mengatur download ke none, atau dengan menentukan pengidentifikasi sumber daya alur lain.

Artefak pekerjaan reguler tidak diunduh secara otomatis. Gunakan download secara eksplisit saat diperlukan.

Artefak dari pipeline sumber daya diunduh ke $(PIPELINE. WORKSPACE)/<folder pipeline-identifier>/<artifact-identifier> . Untuk informasi selengkapnya, lihat Menerbitkan dan mengunduh artefak alur.

Properti opsional artifact menentukan nama artefak. Jika tidak ditentukan, semua artefak yang tersedia diunduh. Properti opsional patterns menentukan pola yang mewakili file untuk disertakan. Untuk informasi skema lengkap, lihat definisi steps.download.

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

Variabel sumber daya alur

Dalam setiap eksekusi, metadata untuk sumber daya alur tersedia untuk semua pekerjaan sebagai variabel yang telah ditentukan sebelumnya. Variabel ini hanya tersedia untuk alur Anda pada runtime, dan oleh karena itu tidak dapat digunakan dalam ekspresi templat, yang dievaluasi pada waktu kompilasi alur.

Untuk informasi selengkapnya, lihat Metadata sumber daya alur sebagai variabel yang telah ditentukan sebelumnya. Untuk mempelajari selengkapnya tentang sintaks variabel, lihat Menentukan variabel.

Contoh berikut mengembalikan nilai variabel yang telah ditentukan sebelumnya untuk myresourcevars sumber daya alur.

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Membangun definisi sumber daya

Jika Anda memiliki sistem build CI eksternal yang menghasilkan artefak, Anda dapat menggunakan artefak dengan builds sumber daya. Sumber build daya dapat berasal dari sistem CI eksternal apa pun seperti Jenkins, TeamCity, atau CircleCI.

Kategori builds ini dapat diperluas. Anda dapat menulis ekstensi untuk menggunakan artefak dari layanan build Anda, dan memperkenalkan jenis layanan baru sebagai bagian buildsdari .

build Dalam definisi, version default ke build terbaru yang berhasil. trigger tidak diaktifkan secara default dan harus diatur secara eksplisit. Untuk informasi skema lengkap, lihat definisi resources.builds.build.

Dalam contoh berikut, Jenkins adalah sumber daya type.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

Penting

Pemicu didukung untuk Jenkins yang dihosting hanya di mana Azure DevOps memiliki garis pandang dengan server Jenkins.

Tugas downloadBuild

Artefak build sumber daya tidak diunduh secara otomatis dalam pekerjaan/pekerjaan penyebaran Anda. Untuk menggunakan artefak dari build sumber daya sebagai bagian dari pekerjaan Anda, Anda perlu menambahkan downloadBuild tugas secara eksplisit. Anda dapat menyesuaikan perilaku pengunduhan untuk setiap penyebaran atau pekerjaan.

Tugas ini secara otomatis diselesaikan ke tugas pengunduhan yang sesuai untuk jenis build sumber daya yang ditentukan runtime. Artefak dari build sumber daya diunduh ke $(PIPELINE. WORKSPACE)/<build-identifier>/ folder.

downloadBuild Dalam definisi, Anda menentukan sumber daya untuk mengunduh artefak. Properti opsional artifact menentukan artefak yang akan diunduh. Jika tidak ditentukan, semua artefak yang terkait dengan sumber daya diunduh.

Properti opsional patterns mendefinisikan jalur minimatch atau daftar jalur minimatch untuk diunduh. Jika kosong, seluruh artefak diunduh. Misalnya, cuplikan berikut hanya mengunduh file *.zip .

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

Untuk informasi skema lengkap, lihat definisi steps.downloadBuild.

Definisi sumber daya repositori

Kata repository kunci memungkinkan Anda menentukan repositori eksternal. Anda dapat menggunakan sumber daya ini jika alur Anda memiliki templat di repositori lain atau Anda ingin menggunakan cek keluar multi-repo dengan repositori yang memerlukan koneksi layanan. Anda harus memberi tahu sistem tentang repositori ini.

Contohnya:

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

Untuk informasi skema lengkap, lihat definisi resources.repositories.repository.

Jenis sumber daya repositori

Azure Pipelines mendukung nilai berikut untuk jenis repositori: git, , githubgithubenterprise, dan bitbucket.

  • Jenisnya git mengacu pada repositori Azure Repos Git.
  • Repositori GitHub Enterprise memerlukan koneksi layanan GitHub Enterprise untuk otorisasi.
  • Repositori Bitbucket Cloud memerlukan koneksi layanan Bitbucket Cloud untuk otorisasi.
Jenis Nilai nama Contoh
type: git Repositori lain dalam proyek yang sama atau organisasi yang sama. Proyek yang sama: name: otherRepo
Proyek lain dalam organisasi yang sama: name: otherProject/otherRepo.
type: github Nama lengkap repositori GitHub termasuk pengguna atau organisasi. name: Microsoft/vscode
type: githubenterprise Nama lengkap repositori GitHub Enterprise termasuk pengguna atau organisasi. name: Microsoft/vscode
type: bitbucket Nama lengkap repositori Bitbucket Cloud termasuk pengguna atau organisasi. name: MyBitbucket/vscode

Variabel sumber daya repositori

Dalam setiap eksekusi, metadata berikut untuk sumber daya repositori tersedia untuk semua pekerjaan dalam bentuk variabel runtime. <Alias> adalah pengidentifikasi yang Anda berikan sumber daya repositori Anda.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url

Contoh berikut memiliki sumber daya repositori dengan alias common, sehingga variabel sumber daya repositori diakses menggunakan resources.repositories.common.*.

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"

Dalam setiap eksekusi, metadata berikut untuk sumber daya repositori tersedia untuk semua pekerjaan dalam bentuk variabel runtime. <Alias> adalah pengidentifikasi yang Anda berikan sumber daya repositori Anda.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version

Contoh berikut memiliki sumber daya repositori dengan alias common, sehingga variabel sumber daya repositori diakses menggunakan resources.repositories.common.*.

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

Kata kunci checkout untuk repositori

Repositori dari repository sumber daya tidak disinkronkan secara otomatis dalam pekerjaan Anda. checkout Gunakan kata kunci untuk mengambil repositori yang didefinisikan sebagai bagian repository dari sumber daya. Untuk informasi skema lengkap, lihat definisi steps.checkout.

Untuk informasi selengkapnya, lihat Melihat beberapa repositori di alur Anda.

Definisi sumber daya kontainer

Jika Anda perlu menggunakan gambar kontainer sebagai bagian dari alur CI/CD, Anda dapat menggunakan containers sumber daya. Sumber container daya dapat berupa registri Docker publik atau privat atau instans Azure Container Registry.

Anda dapat menggunakan gambar sumber daya kontainer generik sebagai bagian dari pekerjaan Anda, atau menggunakan sumber daya untuk pekerjaan kontainer. Jika alur Anda memerlukan dukungan satu atau beberapa layanan, Anda perlu membuat dan menyambungkan ke kontainer layanan. Anda dapat menggunakan volume untuk berbagi data antar layanan.

Jika Anda perlu menggunakan gambar dari registri Docker sebagai bagian dari alur Anda, Anda dapat menentukan sumber daya kontainer generik. Tidak type diperlukan kata kunci. Contohnya:

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp

Untuk informasi skema lengkap, lihat definisi resources.containers.container.

Catatan

enabled: 'true' Sintaks untuk mengaktifkan pemicu kontainer untuk semua tag gambar berbeda dari sintaks untuk pemicu sumber daya lainnya. Pastikan untuk menggunakan sintaks yang benar untuk sumber daya tertentu.

Jenis sumber daya Azure Container Registry

Untuk menggunakan gambar Azure Container Registry, Anda dapat menggunakan jenis acrsumber daya kontainer kelas satu . Anda dapat menggunakan jenis sumber daya ini sebagai bagian dari pekerjaan Anda dan untuk mengaktifkan pemicu alur otomatis.

Anda memerlukan izin Kontributor atau Pemilik untuk Azure Container Registry untuk menggunakan pemicu alur otomatis. Untuk informasi selengkapnya, lihat Peran dan izin Azure Container Registry.

Untuk menggunakan acr jenis sumber daya, Anda harus menentukan azureSubscriptionnilai , , resourceGroupdan repository untuk registri kontainer Azure Anda. Contoh:

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production*

Catatan

Evaluasi pemicu hanya terjadi pada cabang default. Pastikan untuk mengatur cabang default yang benar atau menggabungkan file YAML ke cabang default saat ini. Untuk informasi selengkapnya tentang cara mengubah cabang default alur, kunjungi Cabang default alur.

Variabel sumber daya kontainer

Setelah Anda menentukan kontainer sebagai sumber daya, metadata gambar kontainer diteruskan ke alur sebagai variabel. Informasi seperti gambar, registri, dan detail koneksi dapat diakses di semua pekerjaan yang digunakan dalam tugas penyebaran kontainer Anda.

Variabel sumber daya kontainer berfungsi dengan Docker dan Azure Container Registry. Anda tidak dapat menggunakan variabel sumber daya kontainer untuk kontainer gambar lokal. Variabel location hanya berlaku untuk acr jenis sumber daya kontainer.

Contoh berikut memiliki koneksi layanan Azure Resource Manager bernama arm-connection. Untuk informasi selengkapnya, lihat Registri, repositori, dan gambar kontainer Azure.

resources:
  containers:
  - container: mycontainer
    type: ACR
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

Definisi sumber daya paket

Anda dapat menggunakan paket NuGet dan npm GitHub sebagai sumber daya dalam alur YAML. Untuk mengaktifkan pemicu alur otomatis saat versi paket baru dirilis, atur properti ke trigger true.

Saat Anda menentukan package sumber daya, tentukan Repositori>/<Nama> paket <di name properti , dan atur paket type sebagai NuGet atau npm. Untuk menggunakan paket GitHub, gunakan autentikasi berbasis token akses pribadi (PAT) dan buat koneksi layanan GitHub yang menggunakan PAT.

Untuk informasi skema lengkap, lihat definisi resources.packages.package.

Secara default, paket tidak diunduh secara otomatis ke dalam pekerjaan. Untuk mengunduh, gunakan getPackage.

Contoh berikut memiliki koneksi layanan GitHub bernama pat-contoso ke paket npm GitHub bernama contoso. Untuk informasi selengkapnya, lihat Paket GitHub.

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

Definisi sumber daya Webhooks

Catatan

Webhook dirilis di Azure DevOps Server 2020.1.

Anda dapat menggunakan artefak dan mengaktifkan pemicu otomatis dengan sumber daya alur, kontainer, build, dan paket. Namun, Anda tidak dapat menggunakan sumber daya ini untuk mengotomatiskan penyebaran Anda berdasarkan peristiwa atau layanan eksternal.

Sumber webhooks daya dalam alur YAML memungkinkan Anda mengintegrasikan alur Anda dengan layanan eksternal seperti GitHub, GitHub Enterprise, Nexus, dan Artifactory untuk mengotomatiskan alur kerja. Anda dapat berlangganan peristiwa eksternal apa pun melalui webhook dan menggunakan peristiwa untuk memicu alur Anda.

Webhook mengotomatiskan alur kerja Anda berdasarkan peristiwa webhook eksternal apa pun yang tidak didukung oleh sumber daya kelas satu seperti alur, build, kontainer, atau paket. Selain itu, untuk layanan lokal di mana Azure DevOps tidak memiliki visibilitas ke dalam proses, Anda dapat mengonfigurasi webhook pada layanan dan memicu alur Anda secara otomatis.

Untuk berlangganan peristiwa webhook, Anda menentukan sumber daya webhook di alur Anda dan mengarahkannya ke koneksi layanan webhook masuk. Anda juga dapat menentukan lebih banyak filter pada sumber daya webhook, berdasarkan data payload JSON, untuk menyesuaikan pemicu untuk setiap alur.

Setiap kali koneksi layanan webhook masuk menerima peristiwa webhook, eksekusi baru memicu untuk semua alur yang berlangganan peristiwa webhook. Anda dapat menggunakan data payload JSON dalam pekerjaan Anda sebagai variabel dengan menggunakan format ${{ parameters.<WebhookAlias>.<JSONPath>}}.

Untuk informasi skema lengkap, lihat definisi resources.webhooks.webhook.

Contoh berikut mendefinisikan sumber daya webhook:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

steps:  
- script: echo ${{ parameters.WebHook.resource.message.title }}

Pemicu webhook

Untuk mengonfigurasi pemicu webhook, Anda terlebih dahulu menyiapkan webhook di layanan eksternal Anda, memberikan informasi berikut:

  • Url Permintaan: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
  • Rahasia (Opsional): Jika Anda perlu mengamankan payload JSON Anda, berikan nilai rahasia.

Selanjutnya, Anda membuat koneksi layanan webhook masuk baru. Untuk jenis koneksi layanan ini, Anda menentukan informasi berikut:

  • Nama WebHook: Sama seperti webhook yang dibuat di layanan eksternal Anda.
  • Rahasia (Opsional): Digunakan untuk memverifikasi hash HMAC-SHA1 payload untuk verifikasi permintaan masuk. Jika Anda menggunakan rahasia saat membuat webhook, Anda harus memberikan rahasia yang sama.
  • Header Http: Header HTTP dalam permintaan yang berisi nilai hash HMAC-SHA1 payload untuk verifikasi permintaan. Misalnya, header permintaan GitHub adalah X-Hub-Signature.

Cuplikan layar yang memperlihatkan koneksi layanan webhook masuk.

Untuk memicu alur Anda menggunakan webhook, Anda membuat POST permintaan ke https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Titik akhir ini tersedia untuk umum, dan tidak memerlukan otorisasi. Permintaan harus memiliki isi seperti contoh berikut:

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

Catatan

Mengakses data dari isi permintaan webhook dapat menyebabkan YAML yang salah. Misalnya, langkah - script: echo ${{ parameters.WebHook.resource.message }} alur menarik seluruh pesan JSON, yang menghasilkan YAML yang tidak valid. Alur apa pun yang dipicu melalui webhook ini tidak berjalan, karena YAML yang dihasilkan menjadi tidak valid.

Cuplikan berikut menunjukkan contoh lain yang menggunakan filter webhook.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

Pemilih versi manual untuk sumber daya

Saat Anda memicu alur YAML CD secara manual, Azure Pipelines secara otomatis mengevaluasi versi default untuk sumber daya yang ditentukan dalam alur, berdasarkan input yang disediakan. Namun, Azure Pipelines hanya mempertimbangkan ci run yang berhasil diselesaikan saat mengevaluasi versi default untuk pemicu terjadwal, atau jika Anda tidak memilih versi secara manual.

Anda dapat menggunakan pemilih versi sumber daya untuk memilih versi lain secara manual saat membuat eksekusi. Pemilih versi sumber daya didukung untuk sumber daya alur, build, repositori, kontainer, dan paket.

Untuk sumber daya alur, Anda dapat melihat semua eksekusi yang tersedia di semua cabang, mencarinya berdasarkan nomor atau cabang alur, dan memilih eksekusi yang berhasil, gagal, atau sedang berlangsung. Fleksibilitas ini memastikan bahwa Anda dapat menjalankan alur CD jika Anda yakin eksekusi menghasilkan semua artefak yang Anda butuhkan. Anda tidak perlu menunggu eksekusi CI selesai, atau menjalankannya kembali karena kegagalan tahap yang tidak terkait.

Untuk menggunakan pemilih versi sumber daya, di panel Jalankan alur , pilih Sumber Daya, lalu pilih sumber daya dan pilih versi tertentu dari daftar versi yang tersedia.

Cuplikan layar yang memperlihatkan pemilih versi sumber daya repositori.

Untuk sumber daya di mana Anda tidak dapat mengambil versi yang tersedia, seperti paket GitHub, pemilih versi menyediakan bidang teks sehingga Anda dapat memasukkan versi untuk dipilih.

Otorisasi sumber daya dalam alur YAML

Sumber daya harus diotorisasi sebelum dapat digunakan dalam alur. Pemilik sumber daya mengontrol pengguna dan alur yang dapat mengakses sumber daya mereka. Ada beberapa cara untuk mengotorisasi alur YAML untuk menggunakan sumber daya.

  • Gunakan pengalaman administrasi sumber daya untuk mengotorisasi semua alur untuk mengakses sumber daya. Misalnya, grup variabel dan file aman dikelola di halaman Pustaka di bawah Alur, dan kumpulan agen dan koneksi layanan dikelola di pengaturan Proyek. Otorisasi ini nyaman jika Anda tidak perlu membatasi akses ke sumber daya, seperti untuk sumber daya pengujian.

  • Saat Anda membuat alur, semua sumber daya yang dirujuk dalam file YAML secara otomatis diotorisasi untuk digunakan oleh alur jika Anda memiliki peran Pengguna untuk sumber daya tersebut.

  • Jika Anda menambahkan sumber daya ke file YAML dan build gagal dengan kesalahan seperti Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use., Anda akan melihat opsi untuk mengotorisasi sumber daya pada build yang gagal.

    Jika Anda adalah anggota peran Pengguna untuk sumber daya, Anda dapat memilih opsi ini dan mengotorisasi sumber daya pada build yang gagal. Setelah sumber daya diotorisasi, Anda dapat memulai build baru.

  • Verifikasi bahwa peran keamanan kumpulan agen untuk proyek Anda sudah benar.

Pemeriksaan persetujuan untuk sumber daya

Anda dapat menggunakan pemeriksaan persetujuan dan templat untuk mengontrol secara manual saat sumber daya berjalan. Dengan pemeriksaan persetujuan templat yang diperlukan, Anda dapat mengharuskan alur apa pun menggunakan sumber daya atau lingkungan diperluas dari templat YAML tertentu.

Mengatur persetujuan templat yang diperlukan memastikan bahwa sumber daya Anda hanya digunakan dalam kondisi tertentu, dan meningkatkan keamanan. Untuk mempelajari selengkapnya tentang cara meningkatkan keamanan alur dengan templat, lihat Menggunakan templat untuk keamanan.

Ketertelusuran

Azure Pipelines menyediakan keterlacakan penuh untuk sumber daya apa pun yang digunakan pada tingkat pekerjaan alur atau penyebaran.

Keterlacakan alur

Azure Pipelines memperlihatkan informasi berikut untuk setiap eksekusi alur:

  • Jika sumber daya memicu alur, sumber daya yang memicu alur.
  • Versi sumber daya dan artefak yang digunakan.
  • Menerapkan yang terkait dengan setiap sumber daya.
  • Item kerja yang terkait dengan setiap sumber daya.

Keterlacakan lingkungan

Setiap kali alur disebarkan ke lingkungan, Anda dapat melihat daftar sumber daya yang digunakan. Tampilan ini mencakup sumber daya yang digunakan sebagai bagian dari pekerjaan penyebaran dan penerapan terkait dan item kerjanya.

Cuplikan layar yang memperlihatkan penerapan di lingkungan.

Informasi alur CD terkait dalam alur CI

Untuk menyediakan keterlacakan end-to-end, Anda dapat melacak alur CD mana yang menggunakan alur CI tertentu melalui pipelines sumber daya. Jika alur lain menggunakan alur CI Anda, Anda akan melihat tab Alur terkait di tampilan Jalankan . Tampilan menunjukkan semua eksekusi alur YAML CD yang mengonsumsi alur CI Anda dan artefak darinya.

Cuplikan layar yang memperlihatkan informasi alur CD dalam alur CI.

Masalah pemicu sumber daya

Pemicu sumber daya dapat gagal dijalankan karena:

  • Sumber koneksi layanan yang disediakan tidak valid, ada kesalahan sintaks dalam pemicu, atau pemicu tidak dikonfigurasi.
  • Kondisi pemicu tidak cocok.

Untuk melihat mengapa pemicu alur gagal dijalankan, pilih item menu Masalah pemicu pada halaman definisi alur. Masalah pemicu hanya tersedia untuk sumber daya nonrepositori.

Cuplikan layar yang memperlihatkan Masalah pemicu di halaman alur utama.

Pada halaman Masalah pemicu, pesan kesalahan dan peringatan menjelaskan mengapa pemicu gagal.

Cuplikan layar yang memperlihatkan Dukungan masalah pemicu.

FAQ

Kapan saya harus menggunakan sumber daya alur, pintasan unduhan, atau tugas Unduh Artefak Alur?

pipelines Menggunakan sumber daya adalah cara untuk menggunakan artefak dari alur CI dan juga mengonfigurasi pemicu otomatis. Sumber daya memberi Anda visibilitas penuh ke dalam proses dengan menampilkan versi yang digunakan, artefak, penerapan, dan item kerja. Saat Anda menentukan sumber daya alur, artefak terkait secara otomatis diunduh dalam pekerjaan penyebaran.

Anda dapat menggunakan download pintasan untuk mengunduh artefak dalam pekerjaan build atau untuk mengambil alih perilaku pengunduhan dalam pekerjaan penyebaran. Untuk informasi selengkapnya, lihat definisi steps.download.

Tugas Unduh Artefak Alur tidak memberikan keterlacakan atau pemicu, tetapi terkadang masuk akal untuk menggunakan tugas ini secara langsung. Misalnya, Anda mungkin memiliki tugas skrip yang disimpan dalam templat berbeda yang memerlukan artefak dari build untuk diunduh. Atau, Anda mungkin tidak ingin menambahkan sumber daya alur ke templat. Untuk menghindari dependensi, Anda dapat menggunakan tugas Unduh Artefak Alur untuk meneruskan semua informasi build ke tugas.

Bagaimana cara memicu eksekusi alur saat gambar Docker Hub saya diperbarui?

Pemicu sumber daya kontainer tidak tersedia untuk Docker Hub untuk alur YAML, jadi Anda perlu menyiapkan alur rilis klasik.

  1. Buat koneksi layanan Docker Hub baru.
  2. Buat alur rilis klasik dan tambahkan artefak Docker Hub. Atur koneksi layanan Anda dan pilih namespace, repositori, versi, dan alias sumber.
  3. Pilih pemicu dan alihkan pemicu penyebaran berkelanjutan ke Aktifkan. Setiap dorongan Docker yang terjadi pada repositori yang dipilih membuat rilis.
  4. Buat tahap dan pekerjaan baru. Tambahkan dua tugas, masuk Docker dan Bash.
    • Tugas Docker memiliki login tindakan dan memasukkan Anda ke Docker Hub.
    • Tugas Bash berjalan docker pull <hub-user>/<repo-name>[:<tag>].

Bagaimana cara memvalidasi dan memecahkan masalah webhook saya?

  1. Membuat koneksi layanan.

  2. Referensikan koneksi layanan Anda dan beri nama webhook Anda di bagian .webhooks

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Jalankan alur Anda. Webhook dibuat di Azure sebagai tugas terdistribusi untuk organisasi Anda.

  4. POST Lakukan panggilan API dengan JSON yang valid dalam isi ke https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Jika Anda menerima respons kode status 200, webhook Anda siap dikonsumsi oleh alur Anda.

Jika Anda menerima respons kode status 500 dengan kesalahan Cannot find webhook for the given webHookId ..., kode Anda mungkin berada di cabang yang bukan cabang default Anda. Untuk mengatasi masalah ini:

  1. Pilih Edit di halaman alur Anda.
  2. Dari menu Tindakan lainnya, pilih Pemicu.
  3. Pilih tab YAML lalu pilih Dapatkan sumber.
  4. Di bawah Cabang default untuk build manual dan terjadwal, perbarui cabang fitur Anda.
  5. Pilih Simpan & antrekan.
  6. Setelah alur ini berhasil dijalankan, lakukan POST panggilan API dengan JSON yang valid dalam isi ke https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Anda sekarang akan menerima respons kode status 200.

Konten terkait