Bagikan melalui

Membangun repositori Bitbucket Cloud

  • Artikel

Azure DevOps

Azure Pipelines dapat secara otomatis membangun dan memvalidasi setiap permintaan pull dan berkomitmen ke repositori Bitbucket Cloud Anda. Artikel ini menjelaskan cara mengonfigurasi integrasi antara Bitbucket Cloud dan Azure Pipelines.

Bitbucket dan Azure Pipelines adalah dua layanan independen yang terintegrasi dengan baik bersama-sama. Pengguna Bitbucket Cloud Anda tidak secara otomatis mendapatkan akses ke Azure Pipelines. Anda harus menambahkannya secara eksplisit ke Azure Pipelines.

Akses ke repositori Bitbucket

Anda membuat alur baru dengan terlebih dahulu memilih repositori Bitbucket Cloud lalu file YAML di repositori tersebut. Repositori tempat file YAML ada disebut self repositori. Secara default, cara ini adalah repositori yang dibuat oleh alur Anda.

Anda nantinya dapat mengonfigurasi alur untuk memeriksa repositori yang berbeda atau beberapa repositori. Untuk mempelajari cara melakukannya, lihat cek keluar multi-repositori.

Azure Pipelines harus diberikan akses ke repositori Anda untuk mengambil kode selama build. Selain itu, pengguna yang menyiapkan alur harus memiliki akses admin ke Bitbucket, karena identitas tersebut digunakan untuk mendaftarkan webhook di Bitbucket.

Ada 2 jenis autentikasi untuk memberikan akses Azure Pipelines ke repositori Bitbucket Cloud Anda saat membuat alur.

Jenis autentikasi Alur berjalan menggunakan
1. OAuth Identitas Bitbucket pribadi Anda
2. Nama pengguna dan kata sandi Identitas Bitbucket pribadi Anda

Autentikasi OAuth

OAuth adalah jenis autentikasi paling sederhana untuk memulai repositori di akun Bitbucket Anda. Pembaruan status Bitbucket akan dilakukan atas nama identitas Bitbucket pribadi Anda. Agar alur tetap berfungsi, akses repositori Anda harus tetap aktif.

Untuk menggunakan OAuth, masuk ke Bitbucket saat diminta selama pembuatan alur. Kemudian, klik Otorisasi untuk mengotorisasi dengan OAuth. Koneksi OAuth akan disimpan dalam proyek Azure DevOps Anda untuk digunakan nanti, serta digunakan dalam alur yang sedang dibuat.

Catatan

Jumlah maksimum repositori Bitbucket yang dapat dimuat oleh antarmuka pengguna Azure DevOps Services adalah 2.000.

Autentikasi kata sandi

Pembaruan build dan status Bitbucket akan dilakukan atas nama identitas pribadi Anda. Agar build tetap berfungsi, akses repositori Anda harus tetap aktif.

Untuk membuat koneksi kata sandi, kunjungi Koneksi layanan di pengaturan proyek Azure DevOps Anda. Buat koneksi layanan Bitbucket baru dan berikan nama pengguna dan kata sandi untuk terhubung ke repositori Bitbucket Cloud Anda.

Pemicu CI

Pemicu integrasi berkelanjutan (CI) menyebabkan alur berjalan setiap kali Anda mendorong pembaruan ke cabang yang ditentukan atau Anda mendorong tag yang ditentukan.

Alur YAML dikonfigurasi secara default dengan pemicu CI di semua cabang, kecuali pengaturan Nonaktifkan pemicu YAML CI tersirat, yang diperkenalkan di Azure DevOps sprint 227, diaktifkan. Pengaturan Nonaktifkan pemicu YAML CI tersirat dapat dikonfigurasi di tingkat organisasi atau di tingkat proyek. Ketika pengaturan Nonaktifkan pemicu YAML CI tersirat diaktifkan, pemicu CI untuk alur YAML tidak diaktifkan jika alur YAML tidak memiliki trigger bagian. Secara default, Nonaktifkan pemicu YAML CI tersirat tidak diaktifkan.

Cabang

Anda dapat mengontrol cabang mana yang mendapatkan pemicu CI dengan sintaks sederhana:

trigger:
- main
- releases/*

Anda dapat menentukan nama lengkap cabang (misalnya, main) atau kartubebas (misalnya, releases/*). Lihat Wildcard untuk informasi tentang sintaks kartubebas .

Catatan

Anda tidak dapat menggunakan variabel dalam pemicu, karena variabel dievaluasi pada runtime (setelah pemicu diaktifkan).

Catatan

Jika Anda menggunakan templat untuk menulis file YAML, maka Anda hanya dapat menentukan pemicu dalam file YAML utama untuk alur. Anda tidak dapat menentukan pemicu dalam file templat.

Untuk pemicu yang lebih kompleks yang menggunakan exclude atau batch, Anda harus menggunakan sintaks lengkap seperti yang ditunjukkan dalam contoh berikut.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Dalam contoh di atas, alur akan dipicu jika perubahan didorong ke main atau ke cabang rilis apa pun. Namun, itu tidak akan dipicu jika perubahan dilakukan pada cabang rilis yang dimulai dengan old.

Jika Anda menentukan exclude klausa tanpa include klausul, maka setara dengan menentukan * dalam include klausa.

Selain menentukan nama cabang dalam branches daftar, Anda juga dapat mengonfigurasi pemicu berdasarkan tag dengan menggunakan format berikut:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Jika Anda tidak menentukan pemicu apa pun, dan pengaturan Nonaktifkan pemicu YAML CI tersirat tidak diaktifkan, defaultnya adalah seolah-olah Anda menulis:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Penting

Saat Anda menentukan pemicu, pemicu menggantikan pemicu implisit default, dan hanya mendorong ke cabang yang secara eksplisit dikonfigurasi untuk disertakan akan memicu alur. Termasuk diproses terlebih dahulu, lalu pengecualian dihapus dari daftar tersebut.

Batching CI berjalan

Jika Anda sering memiliki banyak anggota tim yang sering mengunggah perubahan, Anda mungkin ingin mengurangi jumlah eksekusi yang Anda mulai. Jika Anda mengatur batch ke true, ketika alur berjalan, sistem menunggu hingga eksekusi selesai, lalu memulai eksekusi lain dengan semua perubahan yang belum dibuat.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Catatan

batch tidak didukung dalam pemicu sumber daya repositori.

Untuk mengklarifikasi contoh ini, mari kita katakan bahwa dorongan A untuk main menyebabkan alur di atas berjalan. Saat alur berjalan, dorongan B tambahan dan C terjadi ke repositori. Pembaruan ini tidak segera memulai eksekusi independen baru. Tetapi setelah eksekusi pertama selesai, semua pendorongan hingga titik waktu tersebut di-batch bersama-sama dan eksekusi baru dimulai.

Catatan

Jika alur memiliki beberapa pekerjaan dan tahapan, maka eksekusi pertama masih harus mencapai status terminal dengan menyelesaikan atau melewati semua pekerjaan dan tahapannya sebelum eksekusi kedua dapat dimulai. Untuk alasan ini, Anda harus berhati-hati saat menggunakan fitur ini dalam alur dengan beberapa tahap atau persetujuan. Jika Anda ingin membuat batch build dalam kasus seperti itu, disarankan agar Anda membagi proses CI/CD Anda menjadi dua alur - satu untuk build (dengan batching) dan satu untuk penyebaran.

Jalur

Anda dapat menentukan jalur file untuk disertakan atau dikecualikan.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Saat menentukan jalur, Anda harus secara eksplisit menentukan cabang yang akan dipicu jika Anda menggunakan Azure DevOps Server 2019.1 atau yang lebih rendah. Anda tidak dapat memicu alur hanya dengan filter jalur; Anda juga harus memiliki filter cabang, dan file yang diubah yang cocok dengan filter jalur harus dari cabang yang cocok dengan filter cabang. Jika Anda menggunakan Azure DevOps Server 2020 atau yang lebih baru, Anda dapat menghilangkan branches untuk memfilter semua cabang bersama dengan filter jalur.

Kartu liar didukung untuk filter jalur. Misalnya, Anda dapat menyertakan semua jalur yang cocok src/app/**/myapp*dengan . Anda dapat menggunakan karakter kartubebas (**, *, atau ?) saat menentukan filter jalur.

  • Jalur selalu ditentukan relatif terhadap akar repositori.
  • Jika Anda tidak mengatur filter jalur, folder akar repositori secara implisit disertakan secara default.
  • Jika Anda mengecualikan jalur, Anda juga tidak dapat menyertakannya kecuali Anda memenuhi syarat ke folder yang lebih dalam. Misalnya jika Anda mengecualikan /tools maka Anda dapat menyertakan /tools/trigger-runs-on-these
  • Urutan filter jalur tidak masalah.
  • Jalur di Git peka huruf besar/kecil. Pastikan untuk menggunakan kasus yang sama dengan folder nyata.
  • Anda tidak dapat menggunakan variabel dalam jalur, karena variabel dievaluasi pada runtime (setelah pemicu diaktifkan).

Catatan

Untuk repositori Bitbucket Cloud, menggunakan branches sintaksis adalah satu-satunya cara untuk menentukan pemicu tag. Sintaks tags: tidak didukung untuk Bitbucket.

Memilih keluar dari CI

Menonaktifkan pemicu CI

Anda dapat memilih keluar dari pemicu CI sepenuhnya dengan menentukan trigger: none.

# A pipeline with no CI trigger
trigger: none

Penting

Saat Anda mendorong perubahan ke cabang, file YAML di cabang tersebut dievaluasi untuk menentukan apakah eksekusi CI harus dimulai.

Melewatkan CI untuk penerapan individu

Anda juga dapat memberi tahu Azure Pipelines untuk melompati menjalankan alur yang biasanya akan dipicu oleh pendorongan. Cukup sertakan [skip ci] dalam pesan atau deskripsi salah satu penerapan yang merupakan bagian dari pendorongan, dan Azure Pipelines akan melewati CI yang berjalan untuk pendorongan ini. Anda juga dapat menggunakan salah satu variasi berikut.

  • [skip ci] atau [ci skip]
  • skip-checks: true atau skip-checks:true
  • [skip azurepipelines] atau [azurepipelines skip]
  • [skip azpipelines] atau [azpipelines skip]
  • [skip azp] atau [azp skip]
  • ***NO_CI***

Menggunakan jenis pemicu dalam kondisi

Ini adalah skenario umum untuk menjalankan langkah, pekerjaan, atau tahapan yang berbeda di alur Anda tergantung pada jenis pemicu yang memulai eksekusi. Anda dapat melakukan ini menggunakan variabel Build.Reasonsistem . Misalnya, tambahkan kondisi berikut ke langkah, pekerjaan, atau tahap Anda untuk mengecualikannya dari validasi PR.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Perilaku pemicu saat cabang baru dibuat

Adalah umum untuk mengonfigurasi beberapa alur untuk repositori yang sama. Misalnya, Anda mungkin memiliki satu alur untuk membangun dokumen untuk aplikasi Anda dan yang lain untuk membangun kode sumber. Anda dapat mengonfigurasi pemicu CI dengan filter cabang dan filter jalur yang sesuai di masing-masing alur ini. Misalnya, Anda mungkin ingin satu alur dipicu saat mendorong pembaruan ke docs folder, dan satu lagi untuk dipicu saat Anda mendorong pembaruan ke kode aplikasi Anda. Dalam kasus ini, Anda perlu memahami bagaimana alur dipicu saat cabang baru dibuat.

Berikut adalah perilaku ketika Anda mendorong cabang baru (yang cocok dengan filter cabang) ke repositori Anda:

  • Jika alur Anda memiliki filter jalur, alur akan dipicu hanya jika cabang baru memiliki perubahan pada file yang cocok dengan filter jalur tersebut.
  • Jika alur Anda tidak memiliki filter jalur, alur akan dipicu meskipun tidak ada perubahan di cabang baru.

Wildcard

Saat menentukan cabang, tag, atau jalur, Anda dapat menggunakan nama atau kartubebas yang tepat. Pola kartubebas memungkinkan * untuk mencocokkan nol karakter atau lebih dan ? untuk mencocokkan satu karakter.

  • Jika Anda memulai pola Anda dengan * dalam alur YAML, Anda harus membungkus pola dalam tanda kutip, seperti "*-releases".
  • Untuk cabang dan tag:
    • Kartubebas mungkin muncul di mana saja dalam pola.
  • Untuk jalur:
    • Di Azure DevOps Server 2022 dan yang lebih tinggi, termasuk Layanan Azure DevOps, kartubebas dapat muncul di mana saja dalam pola jalur dan Anda dapat menggunakan * atau ?.
    • Di Azure DevOps Server 2020 dan yang lebih rendah, Anda dapat menyertakan * sebagai karakter akhir, tetapi tidak melakukan sesuatu yang berbeda dari menentukan nama direktori dengan sendirinya. Anda mungkin tidak menyertakan * di tengah filter jalur, dan Anda mungkin tidak menggunakan ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Pemicu PR

Pemicu permintaan pull (PR) menyebabkan alur berjalan setiap kali permintaan pull dibuka dengan salah satu cabang target yang ditentukan, atau ketika pembaruan dilakukan pada permintaan pull tersebut.

Cabang

Anda dapat menentukan cabang target saat memvalidasi permintaan pull Anda. Misalnya, untuk memvalidasi permintaan pull yang menargetkan master dan releases/*, Anda dapat menggunakan pemicu berikut pr .

pr:
- main
- releases/*

Konfigurasi ini memulai eksekusi baru saat pertama kali permintaan pull baru dibuat, dan setelah setiap pembaruan yang dibuat untuk permintaan pull.

Anda dapat menentukan nama lengkap cabang (misalnya, master) atau kartubebas (misalnya, releases/*).

Catatan

Anda tidak dapat menggunakan variabel dalam pemicu, karena variabel dievaluasi pada runtime (setelah pemicu diaktifkan).

Catatan

Jika Anda menggunakan templat untuk menulis file YAML, maka Anda hanya dapat menentukan pemicu dalam file YAML utama untuk alur. Anda tidak dapat menentukan pemicu dalam file templat.

Setiap eksekusi baru membangun penerapan terbaru dari cabang sumber permintaan pull. Ini berbeda dari cara Azure Pipelines membangun permintaan pull di repositori lain (misalnya, Azure Repos atau GitHub), di mana ia membangun penerapan penggabungan. Sayangnya, Bitbucket tidak mengekspos informasi tentang penerapan penggabungan, yang berisi kode gabungan antara cabang sumber dan target permintaan pull.

Jika tidak ada pr pemicu yang muncul di file YAML Anda, validasi permintaan pull secara otomatis diaktifkan untuk semua cabang, seolah-olah Anda menulis pemicu berikut pr . Konfigurasi ini memicu build ketika setiap permintaan pull dibuat, dan ketika penerapan masuk ke cabang sumber dari permintaan pull aktif apa pun.

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Penting

Saat Anda menentukan pr pemicu, pemicu menggantikan pemicu implisit pr default, dan hanya mendorong ke cabang yang secara eksplisit dikonfigurasi untuk disertakan akan memicu alur.

Untuk pemicu yang lebih kompleks yang perlu mengecualikan cabang tertentu, Anda harus menggunakan sintaks lengkap seperti yang ditunjukkan dalam contoh berikut.

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Jalur

Anda dapat menentukan jalur file untuk disertakan atau dikecualikan. Misalnya:

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Tips:

  • Kartubebas tidak didukung dengan filter jalur.
  • Jalur selalu ditentukan relatif terhadap akar repositori.
  • Jika Anda tidak mengatur filter jalur, folder akar repositori secara implisit disertakan secara default.
  • Jika Anda mengecualikan jalur, Anda juga tidak dapat menyertakannya kecuali Anda memenuhi syarat ke folder yang lebih dalam. Misalnya jika Anda mengecualikan /tools maka Anda dapat menyertakan /tools/trigger-runs-on-these
  • Urutan filter jalur tidak masalah.
  • Jalur di Git peka huruf besar/kecil. Pastikan untuk menggunakan kasus yang sama dengan folder nyata.
  • Anda tidak dapat menggunakan variabel dalam jalur, karena variabel dievaluasi pada runtime (setelah pemicu diaktifkan).

Beberapa pembaruan PR

Anda dapat menentukan apakah pembaruan tambahan untuk PR harus membatalkan validasi yang sedang berlangsung berjalan untuk PR yang sama. Default adalah true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Menolak validasi PR

Anda dapat menolak validasi permintaan pull sepenuhnya dengan menentukan pr: none.

# no PR triggers
pr: none

Untuk informasi selengkapnya, lihat Pemicu PR dalam skema YAML.

Catatan

Jika pemicu Anda pr tidak diaktifkan, pastikan Anda belum mengambil alih pemicu YAML PR di UI.

Eksekusi informasi

Eksekusi informasi memberi tahu Anda Azure DevOps gagal mengambil kode sumber alur YAML. Pengambilan kode sumber terjadi sebagai respons terhadap peristiwa eksternal, misalnya, penerapan yang didorong. Ini juga terjadi sebagai respons terhadap pemicu internal, misalnya, untuk memeriksa apakah ada perubahan kode dan memulai eksekusi terjadwal atau tidak. Pengambilan kode sumber dapat gagal karena beberapa alasan, dengan sering meminta pembatasan oleh penyedia repositori git. Keberadaan eksekusi informasi tidak selalu berarti Azure DevOps akan menjalankan alur.

Eksekusi informasi terlihat seperti pada cuplikan layar berikut.

Screenshot of an informational pipeline run.

Anda dapat mengenali eksekusi informasi oleh atribut berikut:

  • Status adalah Canceled
  • Durasi adalah < 1s
  • Nama eksekusi berisi salah satu teks berikut:
    • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
    • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
    • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
    • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
  • Nama eksekusi umumnya berisi kesalahan BitBucket / GitHub yang menyebabkan beban alur YAML gagal
  • Tidak ada tahapan / pekerjaan / langkah-langkah

Pelajari selengkapnya tentang eksekusi informasi.

Pembatasan

Azure Pipelines memuat maksimum 2000 cabang dari repositori ke dalam daftar dropdown di Portal Azure Devops, misalnya ke cabang Default untuk pengaturan build manual dan terjadwal, atau saat memilih cabang saat menjalankan alur secara manual. Jika Anda tidak melihat cabang yang Anda inginkan dalam daftar, ketik nama cabang yang diinginkan secara manual.

FAQ

Masalah yang terkait dengan integrasi Bitbucket termasuk dalam kategori berikut:

  • Pemicu yang gagal: Alur saya tidak dipicu saat saya mendorong pembaruan ke repositori.
  • Versi yang salah: Alur saya berjalan, tetapi menggunakan versi sumber/YAML yang tidak terduga.

Pemicu yang gagal

Saya baru saja membuat alur YAML baru dengan pemicu CI/PR, tetapi alur tidak dipicu.

Ikuti masing-masing langkah ini untuk memecahkan masalah pemicu anda yang gagal:

  • Apakah pemicu YAML CI atau PR Anda ditimpa oleh pengaturan alur di UI? Saat mengedit alur Anda, pilih ... lalu Pemicu.

    Pipeline settings UI.

    Periksa pengaturan Ambil alih pemicu YAML dari sini untuk jenis pemicu (Integrasi berkelanjutan atau validasi permintaan Pull) yang tersedia untuk repositori Anda.

    Override YAML trigger from here.

  • Webhook digunakan untuk mengomunikasikan pembaruan dari Bitbucket ke Azure Pipelines. Di Bitbucket, navigasikan ke pengaturan untuk repositori Anda, lalu ke Webhooks. Verifikasi bahwa webhook ada.

  • Apakah alur Anda dijeda atau dinonaktifkan? Buka editor untuk alur, lalu pilih Pengaturan untuk memeriksa. Jika alur Anda dijeda atau dinonaktifkan, pemicu tidak berfungsi.

  • Sudahkah Anda memperbarui file YAML di cabang yang benar? Jika Anda mendorong pembaruan ke cabang, maka file YAML di cabang yang sama mengatur perilaku CI. Jika Anda mendorong pembaruan ke cabang sumber, maka file YAML yang dihasilkan dari penggabungan cabang sumber dengan cabang target mengatur perilaku PR. Pastikan bahwa file YAML di cabang yang benar memiliki konfigurasi CI atau PR yang diperlukan.

  • Apakah Anda telah mengonfigurasi pemicu dengan benar? Saat Anda menentukan pemicu YAML, Anda dapat menentukan klausul serta mengecualikan dan menyertakan untuk cabang, tag, dan jalur. Pastikan klausul include cocok dengan detail penerapan Anda dan klausa pengecualian tidak mengecualikannya. Periksa sintaks untuk pemicu dan pastikan bahwa itu akurat.

  • Apakah Anda telah menggunakan variabel dalam menentukan pemicu atau jalur? Itu tidak didukung.

  • Apakah Anda menggunakan templat untuk file YAML Anda? Jika demikian, pastikan bahwa pemicu Anda ditentukan dalam file YAML utama. Pemicu yang ditentukan di dalam file templat tidak didukung.

  • Apakah Anda mengecualikan cabang atau jalur yang Anda dorong perubahannya? Uji dengan mendorong perubahan ke jalur yang disertakan dalam cabang yang disertakan. Perhatikan bahwa jalur dalam pemicu peka huruf besar/kecil. Pastikan Anda menggunakan kasus yang sama dengan folder asli saat menentukan jalur dalam pemicu.

  • Apakah Anda hanya mendorong cabang baru? Jika demikian, cabang baru mungkin tidak memulai eksekusi baru. Lihat bagian "Perilaku pemicu saat cabang baru dibuat".

Pemicu CI atau PR saya telah berfungsi dengan baik. Tapi, mereka berhenti bekerja sekarang.

Pertama-tama, lakukan langkah-langkah pemecahan masalah dalam pertanyaan sebelumnya. Kemudian, ikuti langkah-langkah tambahan berikut:

  • Apakah Anda memiliki konflik penggabungan dalam PR Anda? Untuk PR yang tidak memicu alur, buka dan periksa apakah memiliki konflik penggabungan. Atasi konflik penggabungan.

  • Apakah Anda mengalami keterlambatan dalam pemrosesan peristiwa pendorongan atau PR? Anda biasanya dapat memverifikasi ini dengan melihat apakah masalah khusus untuk satu alur atau umum untuk semua alur atau repositori dalam proyek Anda. Jika pendorongan atau pembaruan PR ke salah satu repos menunjukkan gejala ini, kita mungkin mengalami keterlambatan dalam memproses peristiwa pembaruan. Periksa apakah kami mengalami pemadaman layanan di halaman status kami. Jika halaman status menunjukkan masalah, maka tim kami pasti sudah mulai mengerjakannya. Periksa halaman secara berkala untuk pembaruan tentang masalah ini.

Saya tidak ingin pengguna mengambil alih daftar cabang untuk pemicu saat mereka memperbarui file YAML. Bagaimana saya dapat melakukan hal ini?

Pengguna dengan izin untuk berkontribusi kode dapat memperbarui file YAML dan menyertakan/mengecualikan cabang tambahan. Akibatnya, pengguna dapat menyertakan fitur atau cabang pengguna mereka sendiri dalam file YAML mereka dan mendorong pembaruan tersebut ke fitur atau cabang pengguna. Hal ini dapat menyebabkan alur dipicu untuk semua pembaruan pada cabang tersebut. Jika Anda ingin mencegah perilaku ini, maka Anda dapat:

  1. Edit alur di antarmuka pengguna Azure Pipelines.
  2. Navigasi ke menu Pemicu .
  3. Pilih Ambil alih pemicu Integrasi berkelanjutan YAML dari sini.
  4. Tentukan cabang yang akan disertakan atau dikecualikan untuk pemicu.

Saat Anda mengikuti langkah-langkah ini, pemicu CI apa pun yang ditentukan dalam file YAML diabaikan.

Versi salah

Versi file YAML yang salah sedang digunakan dalam alur. Mengapa begitu?

  • Untuk pemicu CI, file YAML yang ada di cabang yang Anda dorong dievaluasi untuk melihat apakah build CI harus dijalankan.
  • Untuk pemicu PR, file YAML yang dihasilkan dari penggabungan cabang sumber dan target PR dievaluasi untuk melihat apakah build PR harus dijalankan.