Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Layanan Azure DevOps | Azure DevOps Server 2022 | Azure DevOps Server 2020
Produk besar memiliki beberapa komponen yang saling bergantung satu sama lain. Komponen-komponen ini sering dibangun secara independen. Ketika komponen upstream (pustaka, misalnya) berubah, dependensi hilir harus dibangun kembali dan divalidasi ulang.
Dalam situasi seperti ini, tambahkan pemicu alur untuk menjalankan alur Anda setelah berhasil menyelesaikan alur pemicu .
Nota
Sebelumnya, Anda mungkin telah menavigasi ke editor klasik untuk alur YAML Anda dan mengonfigurasi pemicu penyelesaian build di UI. Meskipun model itu masih berfungsi, model tersebut tidak lagi direkomendasikan. Pendekatan yang disarankan adalah menentukan pemicu alur langsung dalam file YAML. Pemicu penyelesaian build seperti yang didefinisikan dalam editor klasik memiliki berbagai kelemahan, yang kini telah ditangani dalam pemicu pipeline. Misalnya, tidak ada cara untuk memicu alur pada cabang yang sama dengan alur yang dipicu menggunakan pemicu penyelesaian pembangunan.
Pemicu yang ditentukan menggunakan antarmuka pengguna pengaturan alur lebih diutamakan daripada pemicu YAML. Untuk menghapus pemicu terjadwal UI dari alur YAML, lihat pengaturan UI mengambil alih pemicu terjadwal YAML.
Mengonfigurasi pemicu sumber daya pipa
Untuk memicu sebuah pipeline setelah penyelesaian pipeline lain, konfigurasikan pemicu sumber daya pipeline .
Contoh berikut mengonfigurasi pemicu sumber daya alur sehingga alur bernama app-ci
berjalan setelah eksekusi alur security-lib-ci
selesai.
Contoh ini memiliki dua alur berikut.
security-lib-ci
- Alur ini berjalan terlebih dahulu.# security-lib-ci YAML pipeline steps: - bash: echo "The security-lib-ci pipeline runs first"
app-ci
- Alur ini memiliki pemicu sumber daya alur yang mengonfigurasi alurapp-ci
untuk berjalan secara otomatis setiap kali eksekusi alursecurity-lib-ci
selesai.# app-ci YAML pipeline # We are setting up a pipeline resource that references the security-lib-ci # pipeline and setting up a pipeline completion trigger so that our app-ci # pipeline runs when a run of the security-lib-ci pipeline completes resources: pipelines: - pipeline: securitylib # Name of the pipeline resource. source: security-lib-ci # The name of the pipeline referenced by this pipeline resource. project: FabrikamProject # Required only if the source pipeline is in another project trigger: true # Run app-ci pipeline when any run of security-lib-ci completes steps: - bash: echo "app-ci runs after security-lib-ci completes"
-
- pipeline: securitylib
menentukan nama sumber daya alur. Gunakan label yang ditentukan di sini saat merujuk ke sumber daya alur dari bagian lain dari alur, seperti saat menggunakan variabel sumber daya alur atau mengunduh artefak. -
source: security-lib-ci
menentukan nama pipa yang dirujuk oleh sumber daya pipa ini. Anda dapat mengambil nama pipeline dari portal Azure DevOps di beberapa tempat, seperti halaman utama Pipelines . Secara bawaan, pipeline dinamai sesuai dengan repositori yang berisi pipeline tersebut. Untuk memperbarui nama alur, lihat pengaturan alur . Jika pipeline terdapat dalam folder, sertakan nama folder, termasuk bagian awal\
, misalnya\security pipelines\security-lib-ci
. -
project: FabrikamProject
- Jika alur pemicu berada di proyek Azure DevOps lain, Anda harus menentukan nama proyek. Properti ini bersifat opsional jika alur sumber dan alur yang dipicu berada dalam proyek yang sama. Jika Anda menentukan nilai ini dan rangkaian proses Anda tidak terpicu, lihat catatan di akhir bagian ini. -
trigger: true
- Gunakan sintaks ini untuk memicu alur ketika versi mana pun dari alur sumber selesai. Lihat bagian berikut dalam artikel ini untuk mempelajari cara memfilter versi penyelesaian alur sumber mana yang akan memicu eksekusi. Saat filter ditentukan, eksekusi alur sumber harus cocok dengan semua filter untuk memicu eksekusi.
Jika alur pemicu dan alur yang dipicu menggunakan repositori yang sama, kedua alur akan berjalan menggunakan komit yang sama ketika yang satu memicu yang lain. Ini berguna jika alur pertama Anda membangun kode dan alur kedua mengujinya. Namun, jika kedua jalur pipa menggunakan repositori yang berbeda, jalur pipa yang dipicu akan menggunakan versi kode di cabang yang ditentukan oleh pengaturan Default branch for manual and scheduled builds
, seperti dijelaskan dalam pertimbangan cabang untuk pemicu penyelesaian jalur pipa.
Nota
Dalam beberapa skenario, cabang default untuk build manual dan build terjadwal tidak menyertakan awalan refs/heads
. Misalnya, cabang default mungkin diatur ke main
alih-alih refs/heads/main
. Dalam konteks ini, pemicu dari proyek lain tidak berfungsi. Jika Anda mengalami masalah saat mengatur project
ke nilai selain alur target, Anda dapat memperbarui cabang default untuk menyertakan refs/heads
dengan mengubah nilainya ke cabang yang berbeda, lalu dengan mengubahnya kembali ke cabang default yang ingin Anda gunakan.
Mengonfigurasi pemicu penyelesaian alur tidak didukung dalam templat YAML. Anda masih dapat menentukan sumber daya alur dalam templat.
Filter cabang
Anda dapat secara opsional menentukan cabang yang akan disertakan atau dikecualikan saat mengonfigurasi pemicu. Jika Anda menentukan filter cabang, alur baru akan dijalankan setiap kali alur sumber selesai dengan sukses dan cocok dengan filter cabang. Dalam contoh berikut, alur app-ci
berjalan jika security-lib-ci
selesai pada cabang releases/*
mana pun, kecuali releases/old*
.
# app-ci YAML pipeline
resources:
pipelines:
- pipeline: securitylib
source: security-lib-ci
trigger:
branches:
include:
- releases/*
exclude:
- releases/old*
Untuk memicu pipeline anak pada cabang yang berbeda di mana induknya dipicu, sertakan semua filter cabang di mana induknya dipicu. Dalam contoh berikut, alur app-ci
berjalan jika security-lib-ci
selesai pada cabang releases/*
atau cabang utama, kecuali untuk releases/old*
.
# app-ci YAML pipeline
resources:
pipelines:
- pipeline: securitylib
source: security-lib-ci
trigger:
branches:
include:
- releases/*
- main
exclude:
- releases/old*
Nota
Jika filter cabang Anda tidak berfungsi, coba gunakan awalan refs/heads/
. Misalnya, gunakan refs/heads/releases/old*
alih-alih releases/old*
.
Filter tag
Nota
Dukungan filter tag untuk sumber daya alur memerlukan Azure DevOps Server 2020 Update 1 atau lebih besar.
Properti tags
pada filter trigger
menentukan peristiwa penyelesaian mana yang dapat memicu alur kerja Anda. Jika alur pemicu cocok dengan semua tag dalam daftar tags
, alur akan berjalan.
resources:
pipelines:
- pipeline: MyCIAlias
source: Farbrikam-CI
trigger:
tags: # This filter is used for triggering the pipeline run
- Production # Tags are AND'ed
- Signed
Nota
Sumber daya pipa saluran juga memiliki properti tags
. Properti tags
dari sumber daya pipeline digunakan untuk menentukan jalur pipeline mana yang akan diambil artefaknya, ketika pipeline dipicu secara manual atau melalui pemicu yang dijadwalkan. Untuk informasi selengkapnya, lihat Sumber Daya : alur dan evaluasi versi artefak.
Filter tahapan
Nota
filter tahapan untuk pemicu sumber daya alur memerlukan Azure DevOps Server 2020 Update 1 atau yang lebih besar.
Secara default alur target Anda hanya dipicu saat alur sumber selesai. Jika alur sumber Anda memiliki tahapan, Anda dapat menggunakan filter tahap untuk memicu alur Anda berjalan ketika satu atau beberapa tahap alur sumber selesai (bukan seluruh alur) dengan mengonfigurasi stages
filter dengan satu atau beberapa tahap. Jika Anda menyediakan beberapa tahap, alur yang dipicu berjalan saat semua tahap yang tercantum selesai.
resources:
pipelines:
- pipeline: MyCIAlias
source: Farbrikam-CI
trigger:
stages: # This stage filter is used when evaluating conditions for
- PreProduction # triggering your pipeline. On successful completion of all the stages
- Production # provided, your pipeline will be triggered.
Pertimbangan mengenai cabang
Pemicu pemenuhan aliran menggunakan pengaturan cabang default untuk build manual dan terjadwal untuk menentukan filter cabang versi mana dari alur YAML yang akan dievaluasi saat memutuskan apakah akan menjalankan aliran berdasarkan penyelesaian aliran lain. Secara default pengaturan ini menunjuk ke cabang default repositori.
Ketika sebuah pipeline selesai, runtime Azure DevOps mengevaluasi filter cabang pemicu sumber daya pipeline dari setiap pipeline dengan pemicu penyelesaian pipeline yang mereferensikan pipeline yang telah selesai. Sebuah pipeline dapat memiliki beberapa versi dalam cabang yang berbeda, sehingga runtime mengevaluasi filter cabang pada versi pipeline di cabang yang ditentukan oleh pengaturan Default branch for manual and scheduled builds
. Jika ada kecocokan, pipeline berjalan, tetapi versi pipeline yang berjalan mungkin berada pada cabang yang berbeda tergantung pada apakah pipeline yang dipicu berada di repositori yang sama dengan pipeline yang sudah selesai.
- Jika kedua alur berada di repositori yang berbeda, versi alur yang dipicu di cabang yang ditentukan oleh
Default branch for manual and scheduled builds
dijalankan. - Jika kedua alur berada di repositori yang sama, versi alur yang dipicu di cabang yang sama dengan alur pemicu dijalankan (menggunakan versi alur dari cabang tersebut pada saat kondisi pemicu terpenuhi), bahkan jika cabang tersebut berbeda dari
Default branch for manual and scheduled builds
, dan bahkan jika versi tersebut tidak memiliki filter cabang yang cocok dengan cabang alur yang selesai. Ini karena filter cabang dari cabangDefault branch for manual and scheduled builds
digunakan untuk menentukan apakah alur harus berjalan, dan bukan filter cabang dalam versi yang ada di cabang alur yang sudah selesai.
Jika pemicu penyelesaian alur Anda tampaknya tidak diaktifkan, periksa nilai cabang Default untuk pengaturan build manual dan terjadwal untuk alur yang dipicu. Filter cabang dalam versi alur kerja cabang tersebut digunakan untuk menentukan apakah pemicu penyelesaian alur kerja memulai eksekusi alur kerja. Secara default, Default branch for manual and scheduled builds
diatur ke cabang default repositori, tetapi Anda dapat mengubahnya setelah alur dibuat.
Skenario umum di mana pemicu penyelesaian alur tidak dijalankan adalah ketika cabang baru dibuat, filter cabang pemicu penyelesaian alur dimodifikasi untuk menyertakan cabang baru ini, tetapi ketika alur pertama selesai pada cabang yang sesuai dengan filter cabang baru, pemicu alur kedua tidak dijalankan. Ini terjadi jika filter cabang dalam versi alur di cabang Default branch for manual and scheduled builds
tidak sesuai dengan cabang baru. Untuk mengatasi masalah pemicu ini, Anda memiliki dua opsi berikut.
- Perbarui filter cabang di jalur pipa cabang
Default branch for manual and scheduled builds
agar sesuai dengan cabang baru. - Perbarui cabang Default untuk pengaturan build manual dan terjadwal ke cabang yang memiliki versi pipeline dengan filter cabang yang sesuai dengan cabang baru.
Menggabungkan jenis pemicu
Saat Anda menentukan pemicu CI dan pemicu alur di alur Anda, Anda dapat mengharapkan eksekusi baru dimulai setiap kali pendorongan dilakukan yang cocok dengan filter pemicu CI, dan eksekusi alur sumber selesai yang cocok dengan filter pemicu penyelesaian alur.
Misalnya, pertimbangkan dua alur bernama A
dan B
yang berada di repositori yang sama, keduanya memiliki pemicu CI, dan B
memiliki pemicu penyelesaian alur yang dikonfigurasi untuk penyelesaian alur A
. Jika Anda melakukan push ke repositori:
- Eksekusi baru
A
dimulai, berdasarkan pemicu CI-nya. - Pada saat yang sama, eksekusi baru
B
dimulai, berdasarkan pemicu CI-nya. Proses ini menggunakan artefak dari pemrosesan pipeline sebelumnyaA
. - Ketika
A
selesai, itu memicu pemrosesan berikutnya dariB
, berdasarkan pemicu penyelesaian alur kerja diB
.
Untuk mencegah dua kali pemicu eksekusi B
dalam contoh ini, Anda harus menonaktifkan pemicu CI-nya (trigger: none
) atau pemicu alur kerja (pr: none
).