Bagikan melalui

Sumber daya dalam alur YAML

Layanan Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Artikel ini membahas sumber daya untuk alur YAML. Sumber daya adalah apa pun yang digunakan alur yang ada di luar alur tersebut. Sumber daya dalam alur YAML dapat berupa alur, build, kontainer, paket, repositori, atau webhook lainnya.

Setelah menentukan sumber daya, Anda dapat menggunakannya di mana saja di alur Anda. Untuk informasi dan contoh selengkapnya, lihat Definisi sumber daya.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Anda dapat menggunakan status sumber daya untuk memicu alur secara otomatis dengan mengatur trigger properti dalam definisi sumber daya. Alur resources.triggeringAlias dan resources.triggeringCategory variabel kemudian diatur ke nama dan kategori sumber daya. Variabel ini kosong kecuali Build.Reason variabel diatur ke ResourceTrigger.

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

Catatan

Artikel ini terutama membahas sumber daya dalam alur YAML. Untuk sumber daya di alur Klasik, lihat Tentang sumber daya untuk Azure Pipelines.

Otorisasi sumber daya

Sumber daya harus diotorisasi untuk 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 pengaturan administrasi sumber daya untuk Memberikan izin akses ke semua alur. Misalnya, Anda dapat mengelola file aman dan grup variabel di halamanPustaka>, dan kumpulan agen dan koneksi layanan diAlur> Proyek. Otorisasi ini nyaman untuk sumber daya yang tidak perlu Anda batasi, seperti sumber daya pengujian.

  • Pastikan Anda memiliki setidaknya peran Pengguna dalam peran keamanan kumpulan agen untuk proyek Anda. Alur YAML yang Anda buat secara otomatis diizinkan untuk menggunakan sumber daya tempat Anda memiliki peran Pengguna .

  • Jika Anda menambahkan definisi sumber daya ke alur YAML tetapi 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, pastikan Anda memiliki setidaknya peran Pengguna pada sumber daya. Anda kemudian dapat memilih opsi untuk mengotorisasi sumber daya pada build yang gagal. Setelah sumber daya diotorisasi, Anda dapat memulai build baru.

Pemeriksaan persetujuan atas sumber daya

Anda dapat menggunakan pemeriksaan persetujuan dan templat untuk mengontrol penggunaan sumber daya secara manual. Dengan menggunakan pemeriksaan persetujuan templat yang diperlukan, Anda dapat memerlukan alur apa pun yang menggunakan sumber daya atau lingkungan tertentu untuk memperluas dari templat YAML tertentu.

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

Pemilih versi sumber daya manual

Azure Pipelines mengevaluasi versi default untuk sumber daya berdasarkan definisi sumber dayanya. Untuk eksekusi terjadwal, atau eksekusi manual jika Anda tidak memilih eksekusi secara manual, Azure Pipelines hanya mempertimbangkan untuk menyelesaikan integrasi berkelanjutan (CI) yang berhasil diselesaikan untuk mengevaluasi versi sumber daya default.

Anda dapat menggunakan pemilih versi sumber daya manual untuk memilih versi sumber daya yang berbeda saat Memicu alur penyebaran berkelanjutan (CD) YAML secara manual. Pemilih versi sumber daya didukung untuk sumber daya pipeline, build, repositori, kontainer, dan paket.

Untuk pipeline sumber daya, pemilih versi manual memungkinkan Anda melihat semua eksekusi yang tersedia di semua cabang, mencari eksekusi berdasarkan nomor atau cabang alur, dan memilih eksekusi yang berhasil, gagal, atau sedang berlangsung.

Anda tidak perlu menunggu eksekusi CI selesai, atau menjalankannya kembali karena kegagalan yang tidak terkait, sebelum Anda dapat menjalankan alur CD Anda. Anda memiliki fleksibilitas untuk memilih eksekusi apa pun yang Anda tahu menghasilkan artefak yang Anda butuhkan.

Untuk menggunakan pemilih versi sumber daya, pilih Sumber Daya di panel Jalankan alur , pilih sumber daya, dan pilih versi tertentu dari daftar versi yang tersedia. Untuk sumber daya di mana Anda tidak dapat mengambil versi yang tersedia, seperti paket GitHub, Anda dapat memasukkan versi yang Anda inginkan di bidang teks.

Cuplikan layar yang memperlihatkan pemilih versi sumber daya repositori.

Definisi sumber daya

Sumber daya alur YAML dapat berupa:

Bagian berikut ini menyediakan definisi dan contoh kategori sumber daya alur YAML. Untuk informasi skema lengkap, lihat definisi sumber daya dalam referensi skema YAML untuk Azure Pipelines.

Sumber daya alur

Anda dapat menggunakan sumber daya CI pipeline sebagai pemicu untuk alur kerja CD Anda. Anda juga dapat mereferensikan pipeline sumber daya dari alur Anda untuk mengunduh artefak atau menggunakan variabel sumber daya alur. Hanya Azure Pipelines yang dapat menggunakan pipelines sumber daya.

pipelines Dalam definisi sumber daya:

  • pipeline adalah nama unik yang Anda gunakan untuk mereferensikan sumber daya alur.
  • source adalah nama alur yang menghasilkan artefak alur.

Untuk informasi skema lengkap, lihat definisi resources.pipelines.pipeline .

Contoh definisi sumber daya alur

Contoh definisi sumber daya berikut menggunakan artefak dari alur dalam proyek Azure DevOps 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 menentukan alur dari proyek lain, sertakan project nama dalam definisi sumber daya. Contoh berikut juga menggunakan branch untuk mengatasi versi default saat alur dipicu secara manual atau sesuai jadwal. Input cabang tidak dapat memiliki wildcard.

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

Evaluasi versi sumber daya

Azure Pipelines mengevaluasi versi default untuk sumber daya berdasarkan definisi sumber dayanya. Versi artefak sumber daya default alur bergantung pada apakah alur berjalan secara manual atau sesuai jadwal, atau pemicu berdasarkan hasil eksekusi sumber daya.

Untuk eksekusi alur manual atau terjadwal, nilai versionproperti , branch, dan tags dalam pipeline definisi sumber daya menentukan versi artefak. Input branch tidak dapat memiliki kartubebas, dan tags properti menggunakan AND operator .

Untuk eksekusi terjadwal, atau eksekusi manual jika Anda tidak menggunakan pemilih versi, Azure Pipelines mempertimbangkan hanya berhasil menyelesaikan integrasi berkelanjutan (CI) yang berjalan saat mengevaluasi versi sumber daya default. Untuk eksekusi manual, Anda dapat mengambil alih versi yang ditentukan dengan menggunakan pemilih versi manual.

Tabel berikut mencantumkan pipeline properti definisi sumber daya dan versi artefak yang mereka tentukan.

Properti yang ditentukan Versi artefak
version Build yang memiliki nomor eksekusi yang ditentukan
branch Build terbaru yang berjalan di cabang yang ditentukan
tags Build terbaru yang memiliki semua tag yang ditentukan
branch dan tags Build terbaru berjalan pada cabang yang ditentukan yang memiliki semua tag yang ditentukan
version dan branch Bangun dengan nomor eksekusi yang ditentukan dan cabang yang ditentukan
Tidak Build terbaru di semua cabang

Definisi sumber daya berikut pipeline menggunakan branch properti dan tags untuk mengevaluasi versi default saat alur dijadwalkan atau dipicu secara manual. Versi myCIAlias artefak adalah build terbaru yang dijalankan pada main cabang yang memiliki Production tag dan PreProduction .

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

Pemicu sumber daya alur

Untuk eksekusi alur yang memicu hasil eksekusi sumber daya, trigger pengaturan properti dalam definisi sumber daya menentukan versi artefak sumber daya default. Untuk menggunakan pipeline sumber daya sebagai pemicu untuk menjalankan alur saat ini, Anda harus mengatur trigger properti . Jika Anda tidak menyertakan trigger properti, eksekusi sumber daya tidak memicu eksekusi alur saat ini.

Saat alur memicu berdasarkan trigger nilai dalam pipeline definisi sumber daya, nilai definisi versionsumber daya keseluruhan , branch, dan tags properti diabaikan. Properti trigger menentukan versi 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 berada di cabang yang sama dan penerapan yang meningkatkan peristiwa pemicu.
  • pipeline Jika sumber daya berasal dari repositori yang berbeda dari alur saat ini, pemicu berada di cabang pipeline default repositori sumber daya.

Tabel berikut ini menjelaskan bagaimana trigger properti memengaruhi perilaku pemicu.

Properti pemicu Perilaku pemicu
true Pemicu terjadi ketika alur sumber daya berhasil menyelesaikan eksekusi.
branches Pemicu terjadi ketika alur sumber daya berhasil menyelesaikan eksekusi pada salah include satu cabang.
tags Pemicu terjadi ketika alur sumber daya berhasil menyelesaikan eksekusi yang ditandai dengan semua tag yang ditentukan.
stages Pemicu terjadi ketika alur sumber daya berhasil menjalankan stages.
branches, tags, dan stages Pemicu terjadi ketika eksekusi alur sumber daya yang berhasil memenuhi semua kondisi cabang, tag, dan tahapan.

Contoh berikut menunjukkan definisi sumber daya alur dengan yang sederhana trigger.

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

Contoh berikut menunjukkan sumber daya jalur pipa trigger dengan kondisi cabang.

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

Contoh berikut menggunakan stages filter untuk mengevaluasi kondisi pemicu untuk alur CD. Pemicu stages menggunakan AND operator. Alur CD memicu setelah berhasil menyelesaikan semua tahap yang tercantum.

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

Contoh berikut menggunakan tags filter untuk evaluasi versi default dan untuk pemicunya. Tag trigger menggunakan AND operator. Set tags dalam pipeline definisi sumber daya berbeda dari tag yang diatur pada cabang di repositori Git.

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

Alur proses berikut berjalan setiap kali jalur proses sumber daya SmartHotel-CI:

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

Mengunduh artefak rangkaian

Anda dapat menggunakan download langkah dalam alur YAML untuk mengunduh artefak yang terkait dengan eksekusi saat ini atau dengan sumber daya lain pipeline .

Pengunduhan artefak secara otomatis hanya dalam pekerjaan penyebaran. 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 lain pipeline .

Dalam pekerjaan build reguler, artefak tidak diunduh secara otomatis. Gunakan download secara eksplisit saat diperlukan.

Dalam langkah ini download , properti opsional artifact menentukan nama artefak. Jika tidak ditentukan, semua artefak yang tersedia diunduh.

Properti opsional patterns menentukan pola yang mewakili file untuk diunduh. Untuk informasi skema lengkap, lihat definisi steps.download .

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

Artefak dari unduhan pipeline sumber daya ke $(PIPELINE. WORKSPACE)/<folder pipeline-identifier>/<artifact-identifier> . Untuk informasi selengkapnya, lihat Publikasi dan unduhan artefak alur kerja. Untuk alternatif cara mengunduh artefak pipeline, silakan lihat Mengunduh artefak.

Variabel sumber daya alur

Metadata untuk sumber daya alur tersedia untuk semua pekerjaan di setiap eksekusi sebagai variabel yang telah ditentukan sebelumnya. Variabel-variabel ini hanya tersedia untuk pipeline Anda saat runtime, dan oleh karena itu tidak dapat digunakan dalam ekspresi template, yang dievaluasi pada saat waktu kompilasi pipeline.

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

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 sumber daya

Jika Anda memiliki sistem build CI yang menghasilkan artefak, Anda dapat menggunakan artefak dengan builds sumber daya.

Kategori builds ini dapat diperluas. Sumber build daya dapat berasal dari sistem CI eksternal apa pun seperti Jenkins, TeamCity, atau CircleCI. Anda dapat menggunakan builds untuk menulis ekstensi untuk menggunakan artefak dari layanan build Anda atau memperkenalkan jenis layanan baru.

Dalam definisi build, version secara default menjadi build terbaru yang berhasil. Anda harus secara eksplisit mengatur trigger jika diinginkan. Untuk informasi skema lengkap, lihat definisi resources.builds.build .

Dalam contoh berikut, Jenkins adalah jenis sumber daya.

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 jika Azure DevOps memiliki garis pandang dengan server Jenkins.

Tugas downloadBuild tersebut

Artefak build sumber daya tidak secara otomatis diunduh ke pekerjaan/deploy-jobs. 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 downloadBuild secara otomatis diselesaikan ke tugas unduhan yang sesuai untuk jenis build sumber daya yang ditentukan runtime. Artefak dari unduhan build sumber daya 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 unduhan sumber daya.

Properti opsional patterns menentukan jalur minimatch atau daftar jalur minimatch yang akan diunduh. Jika kosong, seluruh artefak akan diunduh. Contoh berikut hanya mengunduh * file.zip .

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

Untuk informasi skema lengkap, lihat definisi steps.downloadBuild .

Sumber daya repositori

repository Gunakan kata kunci untuk memberi tahu sistem tentang repositori eksternal jika:

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 gitmendukung jenis repositori , github, githubenterprise, 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.

Tabel berikut ini menjelaskan repository jenis sumber daya:

Jenis Nilai nama Contoh
git Repositori yang berbeda dalam proyek yang sama atau organisasi yang sama. Proyek yang sama: name: otherRepo
Proyek lain dalam organisasi yang sama:
name: otherProject/otherRepo.
github Nama lengkap repositori GitHub termasuk pengguna atau organisasi. name: myOrganization/otherRepo
githubenterprise Nama lengkap repositori GitHub Enterprise termasuk pengguna atau organisasi. name: myEnterpriseOrg/otherRepo
bitbucket Nama lengkap repositori Bitbucket Cloud termasuk pengguna atau organisasi. name: MyBitbucketOrg/otherRepo

Variabel sumber daya repositori

Metadata untuk sumber daya repositori tersedia untuk semua pekerjaan di setiap eksekusi sebagai variabel runtime. <alias> adalah repository pengidentifikasi dari definisi sumber daya Andarepository.

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

Definisi sumber daya berikut repository memiliki alias , commonsehingga Anda mengakses variabel sumber daya repositori 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)"

Metadata untuk sumber daya repositori tersedia untuk semua pekerjaan di setiap eksekusi sebagai variabel runtime. <alias> adalah repository pengidentifikasi dari definisi sumber daya Andarepository.

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 alias , commonsehingga Anda mengakses variabel sumber daya repositori 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* pada repositori

Repositori sumber daya repository tidak disinkronkan secara otomatis di pekerjaan Anda. Anda dapat menggunakan checkout kata kunci untuk mengambil repositori yang ditentukan dalam repository sumber daya. Untuk informasi selengkapnya, lihat Memeriksa beberapa repositori di pipelin pilihan Anda. Untuk informasi skema lengkap, lihat definisi steps.checkout .

Sumber daya kontainer

Anda dapat menggunakan containers sumber daya untuk menggunakan gambar kontainer di alur CI/CD Anda. 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 menggunakannya dalam pekerjaan kontainer. Jika alur Anda memerlukan dukungan satu atau beberapa layanan, Anda juga perlu membuat dan menyambungkan ke kontainer layanan. Anda dapat menggunakan volume untuk berbagi data antar layanan.

Jika Anda perlu menggunakan gambar dari registri Docker, Anda dapat menentukan sumber daya kontainer generik tanpa menggunakan type 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 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 mengonsumsi image di Azure Container Registry, Anda dapat menggunakan jenis sumber daya kontainer kelas satu acr. Anda dapat menggunakan jenis sumber daya ini dalam pekerjaan Anda dan untuk mengaktifkan pemicu alur otomatis.

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

Untuk menggunakan acr jenis sumber daya, Anda harus menentukan nilai azureSubscription, resourceGroup, dan repository untuk registri kontainer Azure Anda. Contohnya:

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, lihat 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)

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

Saat Anda menentukan package sumber daya, tentukan paket <repository>\<name> 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 .

Paket tidak diunduh secara otomatis ke dalam pekerjaan secara default. 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

steps:
- getPackage: contoso

Sumber daya Webhook

Catatan

Webhook dirilis di Azure DevOps Server 2020.1.

Anda dapat menggunakan alur, kontainer, build, dan sumber daya paket Azure Pipelines untuk menggunakan artefak dan mengotomatiskan pemicu, tetapi Anda tidak dapat menggunakannya untuk mendasarkan penyebaran pada peristiwa atau layanan eksternal. Webhook mengotomatiskan alur kerja Anda berdasarkan peristiwa webhook eksternal yang tidak didukung sumber daya Azure Pipelines kelas satu. Anda dapat berlangganan peristiwa eksternal melalui webhook dan menggunakan peristiwa untuk memicu alur Anda.

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. Untuk layanan lokal di mana Azure DevOps tidak memiliki visibilitas ke dalam proses, Anda dapat mengonfigurasi webhook pada layanan untuk memicu alur Anda secara otomatis.

Untuk berlangganan peristiwa webhook, Anda menentukan webhook sumber daya di alur Anda dan menentukan koneksi layanan webhook masuk. Untuk informasi skema lengkap, lihat definisi resources.webhooks.webhook .

Anda dapat menggunakan data payload JSON sebagai variabel dalam pekerjaan Anda dengan menggunakan format ${{ parameters.<WebhookAlias>.<JSONPath>}}. Contoh berikut mendefinisikan lalu memanggil sumber daya webhook:

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

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

Anda dapat menentukan 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 tersebut.

Contoh berikut 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}}

Konfigurasi pemicu webhook

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

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

Dikoneksi Layanan Alur > Proyek Azure DevOps>, Anda membuat koneksi layanan webhook masuk baru. Misalnya, Anda dapat menentukan informasi berikut untuk jenis koneksi layanan GitHub:

  • Nama WebHook: Nama koneksi webhook yang Anda buat di layanan eksternal Anda.
  • Rahasia (opsional): Hash HMAC-SHA1 payload untuk memverifikasi permintaan masuk. Jika Anda menggunakan rahasia saat membuat webhook, Anda harus memberikan rahasia yang sama.
  • Header Http (opsional): 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 pipeline Anda dengan menggunakan webhook, Anda membuat permintaan POST 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 yang mirip dengan 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 tidak valid.

Ketertelusuran

Azure Pipelines menyediakan keterlacakan penuh untuk sumber daya apa pun yang digunakan pada tingkat pekerjaan alur atau penyebaran. Azure Pipelines memperlihatkan informasi berikut untuk setiap eksekusi alur yang menggunakan sumber daya:

  • Jika sebuah sumber daya memicu alur, maka sumber daya itulah yang memicu alur tersebut.
  • Versi sumber daya dan artefak yang digunakan.
  • Komitmen yang terkait dengan setiap sumber daya.
  • Item kerja yang terkait dengan setiap sumber daya.

Informasi alur CD terkait untuk 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 pelaksanaan alur YAML CD yang memanfaatkan alur CI Anda dan artefak yang dihasilkan darinya.

Cuplikan layar yang memperlihatkan informasi alur CD dalam alur CI.

Keterlacakan lingkungan

Setelah alur disebarkan ke lingkungan, Anda dapat melihat daftar sumber daya yang digunakannya dan penerapan terkait dan item kerjanya.

Cuplikan layar yang menunjukkan commit di lingkungan.

FAQ

Kapan saya harus menggunakan sumber daya pipeline, pintasan unduhan, atau tugas Mengunduh Artefak Pipeline?

Menggunakan sumber daya pipelines adalah cara untuk memanfaatkan artefak dari pipeline 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. Ketika Anda mendefinisikan sumber daya pipeline, artefak terkait akan secara otomatis diunduh dalam pekerjaan penyebaran.

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

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

Bagaimana cara memicu menjalankan pipeline saat image 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 ubah pemicu penyebaran berkelanjutan menjadi Aktifkan. Setiap dorongan Docker yang terjadi pada repositori yang dipilih membuat rilis.
  4. Buat tahap dan pekerjaan baru. Tambahkan dua tugas, tugas Docker login dan Bash.
    • Tugas Docker memiliki tindakan login dan mendaftarkan 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. Rujuk koneksi layanan Anda dan beri nama webhook Anda di bagian webhooks.

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Jalankan pipeline 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 digunakan oleh pipeline 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 & antri.
  6. Setelah alur ini berhasil dijalankan, lakukan POST panggilan API dengan JSON yang valid sebagai isi ke https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Anda sekarang akan menerima respons kode status 200.

Mengapa pemicu sumber daya saya tidak berfungsi?

Pemicu sumber daya dapat gagal dijalankan karena:

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

Untuk melihat mengapa pemicu alur kerja gagal dieksekusi, pilih item menu Masalah pemicu pada halaman definisi alur kerja. Masalah pemicu tidak tersedia untuk sumber daya repositori.

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 menunjukkan dukungan untuk menanggulangi masalah pemicu.

Konten terkait

  • Last updated on