Membangun repositori GitHub

  • Artikel

Azure DevOps

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

Jika Anda baru menggunakan integrasi alur dengan GitHub, ikuti langkah-langkah dalam Membuat alur pertama Anda. Kembali ke artikel ini untuk mempelajari selengkapnya tentang mengonfigurasi dan menyesuaikan integrasi antara GitHub dan Azure Pipelines.

Organisasi dan pengguna

GitHub dan Azure Pipelines adalah dua layanan independen yang terintegrasi dengan baik bersama-sama. Masing-masing memiliki organisasi dan manajemen pengguna mereka sendiri. Bagian ini membuat rekomendasi tentang cara mereplikasi organisasi dan pengguna dari GitHub ke Azure Pipelines.

Organisasi

Struktur GitHub terdiri dari organisasi dan akun pengguna yang berisi repositori. Lihat dokumentasi GitHub.

GitHub organization structure

Struktur Azure DevOps terdiri dari organisasi yang berisi proyek. Lihat Merencanakan struktur organisasi Anda.

Azure DevOps organization structure

Azure DevOps dapat mencerminkan struktur GitHub Anda dengan:

  • Organisasi DevOps untuk organisasi GitHub atau akun pengguna Anda
  • Proyek DevOps untuk repositori GitHub Anda

GitHub structure mapped to Azure DevOps

Untuk menyiapkan struktur yang identik di Azure DevOps:

  1. Buat organisasi DevOps bernama sesuai organisasi GitHub atau akun pengguna Anda. Ini akan memiliki URL seperti https://dev.azure.com/your-organization.
  2. Di organisasi DevOps, buat proyek bernama sesuai repositori Anda. Mereka akan memiliki URL seperti https://dev.azure.com/your-organization/your-repository.
  3. Di Proyek DevOps, buat alur yang dinamai sesuai dengan organisasi gitHub dan repositori yang mereka bangun, seperti your-organization.your-repository. Kemudian, jelas repositori mana yang mereka cari.

Mengikuti pola ini, repositori GitHub dan Proyek Azure DevOps Anda akan memiliki jalur URL yang cocok. Misalnya:

Service URL
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

Pengguna

Pengguna GitHub Anda tidak secara otomatis mendapatkan akses ke Azure Pipelines. Azure Pipelines tidak menyadari identitas GitHub. Untuk alasan ini, tidak ada cara untuk mengonfigurasi Azure Pipelines untuk secara otomatis memberi tahu pengguna tentang kegagalan build atau kegagalan validasi PR menggunakan identitas GitHub dan alamat email mereka. Anda harus secara eksplisit membuat pengguna baru di Azure Pipelines untuk mereplikasi pengguna GitHub. Setelah membuat pengguna baru, Anda dapat mengonfigurasi izin mereka di Azure DevOps untuk mencerminkan izin mereka di GitHub. Anda juga dapat mengonfigurasi pemberitahuan di DevOps menggunakan identitas DevOps mereka.

Peran organisasi GitHub

Peran anggota organisasi GitHub ditemukan di https://github.com/orgs/your-organization/people (ganti your-organization).

Izin anggota organisasi DevOps ditemukan di https://dev.azure.com/your-organization/_settings/security (ganti your-organization).

Peran dalam organisasi GitHub dan peran yang setara dalam organisasi Azure DevOps ditunjukkan di bawah ini.

Peran organisasi GitHub Setara dengan organisasi DevOps
Pemilik Anggota dari Project Collection Administrators
Manajer penagihan Anggota dari Project Collection Administrators
Anggota Anggota dari Project Collection Valid Users. Secara default, grup Anggota tidak memiliki izin untuk membuat proyek baru. Untuk mengubah izin, atur izin grup Create new projects ke Allow, atau buat grup baru dengan izin yang Anda butuhkan.

Peran akun pengguna GitHub

Akun pengguna GitHub memiliki satu peran, yaitu kepemilikan akun.

Izin anggota organisasi DevOps ditemukan di https://dev.azure.com/your-organization/_settings/security (ganti your-organization).

Peran akun pengguna GitHub dipetakan ke izin organisasi DevOps sebagai berikut.

Peran akun pengguna GitHub Setara dengan organisasi DevOps
Pemilik Anggota dari Project Collection Administrators

Izin repositori GitHub

Izin repositori GitHub ditemukan di https://github.com/your-organization/your-repository/settings/collaboration (ganti your-organization dan your-repository).

Izin proyek DevOps ditemukan di https://dev.azure.com/your-organization/your-project/_settings/security (ganti your-organization dan your-project).

Izin yang setara antara repositori GitHub dan Proyek Azure DevOps adalah sebagai berikut.

Izin repositori GitHub Setara dengan proyek DevOps
Admin Anggota dari Project Administrators
Tulis Anggota dari Contributors
Baca Anggota dari Readers

Jika repositori GitHub Anda memberikan izin kepada tim, Anda dapat membuat tim yang cocok di Teams bagian pengaturan proyek Azure DevOps Anda. Kemudian, tambahkan tim ke grup keamanan di atas, sama seperti pengguna.

Izin khusus alur

Untuk memberikan izin kepada pengguna atau tim untuk alur tertentu dalam proyek DevOps, ikuti langkah-langkah berikut:

  1. Kunjungi halaman Alur proyek (misalnya, https://dev.azure.com/your-organization/your-project/_build).
  2. Pilih alur untuk mengatur izin tertentu.
  3. Dari menu konteks '...', pilih Keamanan.
  4. Pilih Tambahkan... untuk menambahkan pengguna, tim, atau grup tertentu dan menyesuaikan izin mereka untuk alur.

Akses ke repositori GitHub

Anda membuat alur baru dengan terlebih dahulu memilih repositori GitHub 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 memicu build mereka, dan mengambil kodenya selama build.

Ada tiga jenis autentikasi untuk memberikan akses Azure Pipelines ke repositori GitHub Anda saat membuat alur.

Jenis autentikasi Alur berjalan menggunakan Bekerja dengan Pemeriksaan GitHub
1. Aplikasi GitHub Identitas Azure Pipelines Ya
2. OAuth Identitas GitHub pribadi Anda No
3. Token akses pribadi (PAT) Identitas GitHub pribadi Anda No

Autentikasi aplikasi GitHub

Aplikasi GitHub Azure Pipelines adalah jenis autentikasi yang direkomendasikan untuk alur integrasi berkelanjutan. Setelah Anda menginstal Aplikasi GitHub di akun gitHub atau organisasi Anda, alur Anda akan berjalan tanpa menggunakan identitas GitHub pribadi Anda. Build dan pembaruan status GitHub akan dilakukan menggunakan identitas Azure Pipelines. Aplikasi ini bekerja dengan GitHub Checks untuk menampilkan build, pengujian, dan cakupan kode menghasilkan GitHub.

Untuk menggunakan Aplikasi GitHub, instal di organisasi GitHub atau akun pengguna Anda untuk beberapa atau semua repositori. Aplikasi GitHub dapat diinstal dan dihapus instalannya dari beranda aplikasi.

Setelah penginstalan, Aplikasi GitHub akan menjadi metode autentikasi default Azure Pipelines ke GitHub (bukan OAuth) saat alur dibuat untuk repositori.

Jika Anda menginstal Aplikasi GitHub untuk semua repositori di organisasi GitHub, Anda tidak perlu khawatir tentang Azure Pipelines yang mengirim email massal atau secara otomatis menyiapkan alur atas nama Anda. Sebagai alternatif untuk menginstal aplikasi untuk semua repositori, admin repositori dapat menginstalnya satu per satu untuk repositori individual. Ini membutuhkan lebih banyak pekerjaan untuk admin, tetapi tidak memiliki keuntungan atau kerugian.

Izin yang diperlukan di GitHub

Penginstalan aplikasi GitHub Azure Pipelines mengharuskan Anda menjadi pemilik organisasi GitHub atau admin repositori. Selain itu, untuk membuat alur untuk repositori GitHub dengan integrasi berkelanjutan dan pemicu permintaan pull, Anda harus memiliki izin GitHub yang diperlukan yang dikonfigurasi. Jika tidak, repositori tidak akan muncul di daftar repositori saat membuat alur. Bergantung pada jenis autentikasi dan kepemilikan repositori, pastikan bahwa akses yang sesuai dikonfigurasi.

  • Jika repositori berada di akun GitHub pribadi Anda, instal Aplikasi GitHub Azure Pipelines di akun GitHub pribadi Anda, dan Anda akan dapat mencantumkan repositori ini saat membuat alur di Azure Pipelines.

  • Jika repositori berada di akun GitHub pribadi orang lain, orang lain harus menginstal Aplikasi GitHub Azure Pipelines di akun GitHub pribadi mereka. Anda harus ditambahkan sebagai kolaborator di pengaturan repositori di bawah "Kolaborator". Terima undangan untuk menjadi kolaborator menggunakan tautan yang dikirimkan melalui email kepada Anda. Setelah melakukannya, Anda dapat membuat alur untuk repositori tersebut.

  • Jika repositori berada di organisasi GitHub yang Anda miliki, instal Aplikasi GitHub Azure Pipelines di organisasi GitHub. Anda juga harus ditambahkan sebagai kolaborator, atau tim Anda harus ditambahkan, dalam pengaturan repositori di bawah "Kolaborator dan tim".

  • Jika repositori berada di organisasi GitHub yang dimiliki orang lain, pemilik organisasi GitHub atau admin repositori harus menginstal Aplikasi GitHub Azure Pipelines di organisasi. Anda harus ditambahkan sebagai kolaborator, atau tim Anda harus ditambahkan, dalam pengaturan repositori di bawah "Kolaborator dan tim". Terima undangan untuk menjadi kolaborator menggunakan tautan yang dikirimkan melalui email kepada Anda.

Izin Aplikasi GitHub

Aplikasi GitHub meminta izin berikut selama penginstalan:

Izin Cara Azure Pipelines menggunakan izin
Menulis akses ke kode Hanya setelah tindakan yang Anda sengaja, Azure Pipelines akan menyederhanakan pembuatan alur dengan menerapkan file YAML ke cabang repositori GitHub yang dipilih.
Membaca akses ke metadata Azure Pipelines akan mengambil metadata GitHub untuk menampilkan repositori, cabang, dan masalah yang terkait dengan build dalam ringkasan build.
Membaca dan menulis akses ke pemeriksaan Azure Pipelines akan membaca dan menulis hasil cakupan build, pengujian, dan kodenya sendiri untuk ditampilkan di GitHub.
Membaca dan menulis akses ke permintaan pull Hanya setelah tindakan yang anda sengaja, Azure Pipelines akan menyederhanakan pembuatan alur dengan membuat permintaan pull untuk file YAML yang diterapkan ke cabang repositori GitHub yang dipilih. Alur mengambil metadata permintaan untuk ditampilkan dalam ringkasan build yang terkait dengan permintaan pull.

Pemecahan masalah penginstalan Aplikasi GitHub

GitHub mungkin menampilkan kesalahan seperti:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Ini berarti bahwa Aplikasi GitHub kemungkinan sudah diinstal untuk organisasi Anda. Saat Anda membuat alur untuk repositori di organisasi, Aplikasi GitHub akan secara otomatis digunakan untuk terhubung ke GitHub.

Membuat alur di beberapa organisasi dan proyek Azure DevOps

Setelah Aplikasi GitHub diinstal, alur dapat dibuat untuk repositori organisasi di organisasi dan proyek Azure DevOps yang berbeda. Namun, jika Anda membuat alur untuk satu repositori di beberapa organisasi Azure DevOps, hanya alur organisasi pertama yang dapat secara otomatis dipicu oleh penerapan GitHub atau permintaan pull. Build manual atau terjadwal masih dimungkinkan di organisasi Azure DevOps sekunder.

Autentikasi OAuth

OAuth adalah jenis autentikasi paling sederhana untuk memulai repositori di akun GitHub pribadi Anda. Pembaruan status GitHub akan dilakukan atas nama identitas GitHub pribadi Anda. Agar alur tetap berfungsi, akses repositori Anda harus tetap aktif. Beberapa fitur GitHub, seperti Pemeriksaan, tidak tersedia dengan OAuth dan memerlukan Aplikasi GitHub.

Untuk menggunakan OAuth, pilih Pilih koneksi lain di bawah daftar repositori saat membuat alur. Kemudian, pilih Otorisasi untuk masuk ke GitHub dan otorisasi dengan OAuth. Koneksi OAuth akan disimpan di proyek Azure DevOps Anda untuk digunakan nanti, dan digunakan dalam alur yang sedang dibuat.

Izin yang diperlukan di GitHub

Untuk membuat alur untuk repositori GitHub dengan integrasi berkelanjutan dan pemicu permintaan pull, Anda harus memiliki izin GitHub yang diperlukan yang dikonfigurasi. Jika tidak, repositori tidak akan muncul di daftar repositori saat membuat alur. Bergantung pada jenis autentikasi dan kepemilikan repositori, pastikan bahwa akses yang sesuai dikonfigurasi.

  • Jika repositori berada di akun GitHub pribadi Anda, setidaknya sekali, autentikasi ke GitHub dengan OAuth menggunakan kredensial akun GitHub pribadi Anda. Ini dapat dilakukan di pengaturan proyek Azure DevOps di bawah Koneksi > layanan Alur > Koneksi > layanan baru GitHub > Authorize. Berikan akses Azure Pipelines ke repositori Anda di bawah "Izin" di sini.

  • Jika repositori berada di akun GitHub pribadi orang lain, setidaknya sekali, orang lain harus mengautentikasi ke GitHub dengan OAuth menggunakan kredensial akun GitHub pribadi mereka. Ini dapat dilakukan di pengaturan proyek Azure DevOps di bawah Koneksi > layanan Alur > Koneksi > layanan baru GitHub > Authorize. Orang lain harus memberikan akses Azure Pipelines ke repositori mereka di bawah "Izin" di sini. Anda harus ditambahkan sebagai kolaborator di pengaturan repositori di bawah "Kolaborator". Terima undangan untuk menjadi kolaborator menggunakan tautan yang dikirimkan melalui email kepada Anda.

  • Jika repositori berada di organisasi GitHub yang Anda miliki, setidaknya sekali, autentikasi ke GitHub dengan OAuth menggunakan kredensial akun GitHub pribadi Anda. Ini dapat dilakukan di pengaturan proyek Azure DevOps di bawah Koneksi > layanan Alur > Koneksi > layanan baru GitHub > Authorize. Berikan akses Azure Pipelines ke organisasi Anda di bawah "Akses organisasi" di sini. Anda harus ditambahkan sebagai kolaborator, atau tim Anda harus ditambahkan, dalam pengaturan repositori di bawah "Kolaborator dan tim".

  • Jika repositori berada di organisasi GitHub yang dimiliki orang lain, setidaknya sekali, pemilik organisasi GitHub harus mengautentikasi ke GitHub dengan OAuth menggunakan kredensial akun GitHub pribadi mereka. Ini dapat dilakukan di pengaturan proyek Azure DevOps di bawah Koneksi > layanan Alur > Koneksi > layanan baru GitHub > Authorize. Pemilik organisasi harus memberikan akses Azure Pipelines ke organisasi di bawah "Akses organisasi" di sini. Anda harus ditambahkan sebagai kolaborator, atau tim Anda harus ditambahkan, dalam pengaturan repositori di bawah "Kolaborator dan tim". Terima undangan untuk menjadi kolaborator menggunakan tautan yang dikirimkan melalui email kepada Anda.

Mencabut akses OAuth

Setelah mengotorisasi Azure Pipelines untuk menggunakan OAuth, untuk mencabutnya nanti dan mencegah penggunaan lebih lanjut, kunjungi Aplikasi OAuth di pengaturan GitHub Anda. Anda juga dapat menghapusnya dari daftar koneksi layanan GitHub di pengaturan proyek Azure DevOps Anda.

Autentikasi token akses pribadi (PAT)

PATs secara efektif sama dengan OAuth, tetapi memungkinkan Anda mengontrol izin mana yang diberikan ke Azure Pipelines. Build dan pembaruan status GitHub akan dilakukan atas nama identitas GitHub pribadi Anda. Agar build tetap berfungsi, akses repositori Anda harus tetap aktif.

Untuk membuat PAT, kunjungi Token akses pribadi di pengaturan GitHub Anda. Izin yang diperlukan adalah repo, , admin:repo_hookread:user, dan user:email. Ini adalah izin yang sama yang diperlukan saat menggunakan OAuth di atas. Salin PAT yang dihasilkan ke clipboard dan tempelkan ke koneksi layanan GitHub baru di pengaturan proyek Azure DevOps Anda. Untuk pengenalan di masa mendatang, beri nama koneksi layanan setelah nama pengguna GitHub Anda. Ini akan tersedia di proyek Azure DevOps Anda untuk digunakan nanti saat membuat alur.

Izin yang diperlukan di GitHub

Untuk membuat alur untuk repositori GitHub dengan integrasi berkelanjutan dan pemicu permintaan pull, Anda harus memiliki izin GitHub yang diperlukan yang dikonfigurasi. Jika tidak, repositori tidak akan muncul di daftar repositori saat membuat alur. Bergantung pada jenis autentikasi dan kepemilikan repositori, pastikan bahwa akses berikut dikonfigurasi.

  • Jika repositori berada di akun GitHub pribadi Anda, PAT harus memiliki cakupan akses yang diperlukan di bawah Token akses pribadi: repo, , read:useradmin:repo_hook, dan user:email.

  • Jika repositori berada di akun GitHub pribadi orang lain, PAT harus memiliki cakupan akses yang diperlukan di bawah Token akses pribadi: repo, admin:repo_hook, read:user, dan user:email. Anda harus ditambahkan sebagai kolaborator di pengaturan repositori di bawah "Kolaborator". Terima undangan untuk menjadi kolaborator menggunakan tautan yang dikirimkan melalui email kepada Anda.

  • Jika repositori berada di organisasi GitHub yang Anda miliki, PAT harus memiliki cakupan akses yang diperlukan di bawah Token akses pribadi: repo, admin:repo_hook, read:user, dan user:email. Anda harus ditambahkan sebagai kolaborator, atau tim Anda harus ditambahkan, dalam pengaturan repositori di bawah "Kolaborator dan tim".

  • Jika repositori berada di organisasi GitHub yang dimiliki orang lain, PAT harus memiliki cakupan akses yang diperlukan di bawah Token akses pribadi: repo, admin:repo_hook, read:user, dan user:email. Anda harus ditambahkan sebagai kolaborator, atau tim Anda harus ditambahkan, dalam pengaturan repositori di bawah "Kolaborator dan tim". Terima undangan untuk menjadi kolaborator menggunakan tautan yang dikirimkan melalui email kepada Anda.

Mencabut akses PAT

Setelah mengotorisasi Azure Pipelines untuk menggunakan PAT, untuk menghapusnya nanti dan mencegah penggunaan lebih lanjut, kunjungi Token akses pribadi di pengaturan GitHub Anda. Anda juga dapat menghapusnya dari daftar koneksi layanan GitHub di pengaturan proyek Azure DevOps 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).

Tag

Selain menentukan tag dalam daftar seperti yang branches dibahas di bagian sebelumnya, Anda dapat langsung menentukan tag untuk disertakan atau dikecualikan:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Jika Anda tidak menentukan pemicu tag apa pun, maka secara default, tag tidak akan memicu alur.

Penting

Jika Anda menentukan tag dalam kombinasi dengan filter cabang, pemicu akan diaktifkan jika filter cabang terpenuhi atau filter tag terpenuhi. Misalnya, jika tag yang didorong memenuhi filter cabang, alur memicu bahkan jika tag dikecualikan oleh filter tag, karena pendorongan memenuhi filter cabang.

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 main 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, main) 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.

GitHub membuat ref baru saat permintaan pull dibuat. Ref menunjuk ke penerapan penggabungan, yang merupakan kode gabungan antara cabang sumber dan target permintaan pull. Alur validasi PR membangun penerapan yang ditunjukkan oleh ref ini. Ini berarti bahwa file YAML yang digunakan untuk menjalankan alur juga merupakan penggabungan antara sumber dan cabang target. Akibatnya, perubahan yang Anda buat pada file YAML di cabang sumber permintaan pull dapat menimpa perilaku yang ditentukan oleh file YAML di cabang target.

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 dengan subset cabang, alur hanya dipicu saat pembaruan didorong ke cabang tersebut.

Untuk pemicu yang lebih kompleks yang perlu mengecualikan cabang tertentu, Anda harus menggunakan sintaks lengkap seperti yang ditunjukkan dalam contoh berikut. Dalam contoh ini, permintaan pull divalidasi bahwa target main atau releases/* dan cabang releases/old* dikecualikan.

# 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:

  • Azure Pipelines memposting status netral kembali ke GitHub ketika memutuskan untuk tidak menjalankan build validasi karena aturan pengecualian jalur. Ini memberikan arah yang jelas ke GitHub yang menunjukkan bahwa Azure Pipelines telah menyelesaikan pemrosesannya. Untuk informasi selengkapnya, lihat Memposting status netral ke GitHub saat build dilewati.
  • Kartubebas sekarang 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).
  • Azure Pipelines memposting status netral kembali ke GitHub ketika memutuskan untuk tidak menjalankan build validasi karena aturan pengecualian jalur.

Beberapa pembaruan PR

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

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

Validasi Draf PR

Secara default, pemicu permintaan pull diaktifkan pada draf permintaan pull dan permintaan pull yang siap untuk ditinjau. Untuk menonaktifkan pemicu permintaan pull untuk draf permintaan pull, atur properti ke draftsfalse.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

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, ikuti langkah-langkah pemecahan masalah di FAQ.

Jika Anda memiliki PR terbuka dan mendorong perubahan ke cabang sumbernya, beberapa alur dapat berjalan:

  • Alur yang memiliki pemicu PR pada cabang target PR akan berjalan pada penerapan penggabungan (kode gabungan antara cabang sumber dan target permintaan pull), terlepas dari apakah ada penerapan yang didorong yang pesan atau deskripsinya berisi [skip ci] (atau variannya).
  • Alur yang dipicu oleh perubahan pada cabang sumber PR, jika tidak ada penerapan yang didorong yang pesan atau deskripsinya berisi [skip ci] (atau variannya). Jika setidaknya satu penerapan yang didorong berisi [skip ci], alur tidak akan berjalan.

Terakhir, setelah Anda menggabungkan PR, Azure Pipelines akan menjalankan alur CI yang dipicu oleh pendorongan ke cabang target, jika pesan atau deskripsi penerapan penggabungan tidak berisi [skip ci] (atau variannya).

Cabang yang dilindungi

Anda dapat menjalankan build validasi dengan setiap permintaan penerapan atau penarikan yang menargetkan cabang, dan bahkan mencegah permintaan pull menggabungkan hingga build validasi berhasil.

Untuk mengonfigurasi build validasi wajib untuk repositori GitHub, Anda harus menjadi pemiliknya, kolaborator dengan peran Admin, atau anggota organisasi GitHub dengan peran Tulis.

  1. Pertama, buat alur untuk repositori dan bangun setidaknya sekali sehingga statusnya diposting ke GitHub, sehingga membuat GitHub mengetahui nama alur.

  2. Selanjutnya, ikuti dokumentasi GitHub untuk mengonfigurasi cabang yang dilindungi di pengaturan repositori.

    Untuk pemeriksaan status, pilih nama alur Anda di daftar Pemeriksaan status.

    GitHub pipeline status check

Penting

Jika alur Anda tidak muncul dalam daftar ini, pastikan hal berikut:

Kontribusi dari sumber eksternal

Jika repositori GitHub Anda sumber terbuka, Anda dapat membuat proyek Azure DevOps Anda menjadi publik sehingga siapa pun dapat melihat hasil build, log, dan hasil pengujian alur Anda tanpa masuk. Saat pengguna di luar organisasi Anda fork repositori Anda dan mengirimkan permintaan pull, mereka dapat melihat status build yang secara otomatis memvalidasi permintaan pull tersebut.

Anda harus mengingat pertimbangan berikut saat menggunakan Azure Pipelines dalam proyek publik saat menerima kontribusi dari sumber eksternal.

Pembatasan akses

Perhatikan pembatasan akses berikut saat Anda menjalankan alur di proyek publik Azure DevOps:

  • Rahasia: Secara default, rahasia yang terkait dengan alur Anda tidak tersedia untuk menarik validasi permintaan fork. Lihat Memvalidasi kontribusi dari fork.
  • Akses lintas proyek: Semua alur dalam proyek publik Azure DevOps berjalan dengan token akses yang dibatasi untuk proyek. Alur dalam proyek publik dapat mengakses sumber daya seperti membangun artefak atau hasil pengujian hanya dalam proyek dan bukan di proyek lain dari organisasi Azure DevOps.
  • Paket Azure Artifacts: Jika alur Anda memerlukan akses ke paket dari Azure Artifacts, Anda harus secara eksplisit memberikan izin ke akun Project Build Service untuk mengakses umpan paket.

Kontribusi dari fork

Penting

Pengaturan ini memengaruhi keamanan alur Anda.

Saat Anda membuat alur, alur secara otomatis dipicu untuk permintaan pull dari fork repositori Anda. Anda dapat mengubah perilaku ini, dengan hati-hati mempertimbangkan bagaimana hal itu memengaruhi keamanan. Untuk mengaktifkan atau menonaktifkan perilaku ini:

  1. Buka proyek Azure DevOps Anda. Pilih Alur, temukan alur Anda, dan pilih Edit.
  2. Pilih tab Pemicu . Setelah mengaktifkan pemicu permintaan Pull, aktifkan atau nonaktifkan kotak centang Buat permintaan pull dari fork repositori ini.

Secara default dengan alur GitHub, rahasia yang terkait dengan alur build Anda tidak tersedia untuk menarik build permintaan fork. Rahasia ini diaktifkan secara default dengan alur GitHub Enterprise Server. Rahasia meliputi:

Untuk melewati tindakan pencegahan ini pada alur GitHub, aktifkan kotak centang Buat rahasia tersedia untuk build fork . Ketahui efek pengaturan ini pada keamanan.

Catatan

Saat Anda mengaktifkan build fork untuk mengakses rahasia, Azure Pipelines secara default membatasi token akses yang digunakan untuk build fork. Ini memiliki akses yang lebih terbatas untuk membuka sumber daya daripada token akses normal. Untuk memberi build fork izin yang sama dengan build reguler, aktifkan build Buat fork memiliki izin yang sama dengan pengaturan build reguler.

Untuk informasi selengkapnya, lihat Perlindungan repositori - Fork.

Anda dapat menentukan secara terpusat bagaimana alur membangun PR dari repositori GitHub bercabangan menggunakan batas permintaan pull bangunan dari kontrol repositori GitHub bercabangan. Ini tersedia di tingkat organisasi dan proyek. Anda dapat memilih untuk:

  • Menonaktifkan permintaan pull bangunan dari repositori fork
  • Membangun permintaan pull dengan aman dari repositori fork
  • Menyesuaikan aturan untuk membangun permintaan pull dari repositori fork

Screenshot of centralized control settings for how pipelines build PRs from forked GitHub repositories.

Dimulai dengan Sprint 229, untuk meningkatkan keamanan alur Anda, Azure Pipelines tidak lagi secara otomatis membangun permintaan pull dari repositori GitHub fork. Untuk proyek dan organisasi baru, nilai default pengaturan Batasi permintaan pull bangunan dari repositori GitHub fork adalah Nonaktifkan permintaan pull bangunan dari repositori fork.

Saat Anda memilih opsi Buat permintaan pull dengan aman dari repositori fork, semua alur, organisasi, atau seluruh proyek, tidak dapat membuat rahasia tersedia untuk build PR dari repositori fork, tidak dapat membuat build ini memiliki izin yang sama dengan build normal, dan harus dipicu oleh komentar PR. Proyek masih dapat memutuskan untuk tidak mengizinkan alur untuk membangun PR tersebut.

Saat Anda memilih opsi Kustomisasi , Anda dapat menentukan cara membatasi pengaturan alur. Misalnya, Anda dapat memastikan bahwa semua alur memerlukan komentar untuk membangun PR dari repositori GitHub bercabangan, ketika PR milik anggota non-tim dan non-kontributor. Tetapi, Anda dapat memilih untuk mengizinkan mereka membuat rahasia tersedia untuk build tersebut. Proyek dapat memutuskan untuk tidak mengizinkan alur untuk membangun PR tersebut, atau membangunnya dengan aman, atau memiliki pengaturan yang lebih ketat daripada yang ditentukan di tingkat organisasi.

Kontrol nonaktif untuk organisasi yang ada. Mulai September 2023, organisasi baru telah membangun permintaan pull dengan aman dari repositori fork yang diaktifkan secara default.

Pertimbangan keamanan penting

Pengguna GitHub dapat membuat fork repositori Anda, mengubahnya, dan membuat permintaan pull untuk mengusulkan perubahan pada repositori Anda. Permintaan pull ini dapat berisi kode berbahaya untuk dijalankan sebagai bagian dari build yang dipicu. Kode tersebut dapat menyebabkan kerusakan dengan cara berikut:

  • Bocorkan rahasia dari alur Anda. Untuk mengurangi risiko ini, jangan aktifkan kotak centang Buat rahasia tersedia untuk build fork jika repositori Anda adalah pengguna publik atau tidak tepercaya dapat mengirimkan permintaan pull yang secara otomatis memicu build. Pemadatan dinonaktifkan secara default.

  • Kompromi komputer yang menjalankan agen untuk mencuri kode atau rahasia dari alur lain. Untuk mengurangi hal ini:

    • Gunakan kumpulan agen yang dihosting Microsoft untuk membangun permintaan pull dari fork. Komputer agen yang dihosting Microsoft segera dihapus setelah menyelesaikan build, sehingga tidak ada dampak yang abadi jika disusupi.

    • Jika Anda harus menggunakan agen yang dihost sendiri, jangan menyimpan rahasia apa pun atau melakukan build dan rilis lain yang menggunakan rahasia pada agen yang sama, kecuali repositori Anda bersifat privat dan Anda mempercayai pembuat permintaan pull.

Pemicu komentar

Kolaborator repositori dapat mengomentari permintaan pull untuk menjalankan alur secara manual. Berikut adalah beberapa alasan umum mengapa Anda mungkin ingin melakukan ini:

  • Anda mungkin tidak ingin secara otomatis membangun permintaan pull dari pengguna yang tidak dikenal hingga perubahan mereka dapat ditinjau. Anda ingin salah satu anggota tim Anda terlebih dahulu meninjau kode mereka lalu menjalankan alur. Ini biasanya digunakan sebagai ukuran keamanan saat membangun kode yang dikontribusikan dari repositori fork.
  • Anda mungkin ingin menjalankan rangkaian pengujian opsional atau satu build validasi lagi.

Untuk mengaktifkan pemicu komentar, Anda harus mengikuti dua langkah berikut:

  1. Aktifkan pemicu permintaan pull untuk alur Anda, dan pastikan Anda tidak mengecualikan cabang target.
  2. Di portal web Azure Pipelines, edit alur Anda dan pilih Tindakan lainnya, Pemicu. Kemudian, di bawah Validasi permintaan Pull, aktifkan Wajibkan komentar anggota tim sebelum membuat permintaan pull.
    • Pilih Pada semua permintaan pull untuk mewajibkan komentar anggota tim sebelum membuat permintaan pull. Dengan alur kerja ini, anggota tim meninjau permintaan pull dan memicu build dengan komentar setelah permintaan pull dianggap aman.
    • Pilih Hanya pada permintaan pull dari anggota non-tim untuk mewajibkan komentar anggota tim hanya ketika PR dibuat oleh anggota non-tim. Dalam alur kerja ini, anggota tim tidak memerlukan tinjauan anggota tim sekunder untuk memicu build.

Dengan kedua perubahan ini, build validasi permintaan pull tidak akan dipicu secara otomatis, kecuali hanya pada permintaan pull dari anggota non-tim dipilih dan PR dibuat oleh anggota tim. Hanya pemilik repositori dan kolaborator dengan izin 'Tulis' yang dapat memicu build dengan mengomentari permintaan pull dengan /AzurePipelines run atau /AzurePipelines run <pipeline-name>.

Perintah berikut dapat dikeluarkan untuk Azure Pipelines dalam komentar:

Perintah Hasil
/AzurePipelines help Tampilkan bantuan untuk semua perintah yang didukung.
/AzurePipelines help <command-name> Tampilkan bantuan untuk perintah yang ditentukan.
/AzurePipelines run Jalankan semua alur yang terkait dengan repositori ini dan yang pemicunya tidak mengecualikan permintaan pull ini.
/AzurePipelines run <pipeline-name> Jalankan alur yang ditentukan kecuali pemicunya mengecualikan permintaan pull ini.

Catatan

Untuk brevity, Anda dapat berkomentar menggunakan /azp alih-alih /AzurePipelines.

Penting

Respons terhadap perintah ini akan muncul dalam diskusi permintaan pull hanya jika alur Anda menggunakan Aplikasi GitHub Azure Pipelines.

Memecahkan masalah pemicu komentar permintaan pull

Jika Anda memiliki izin repositori yang diperlukan, tetapi alur tidak dipicu oleh komentar Anda, pastikan keanggotaan Anda bersifat publik di organisasi repositori, atau secara langsung menambahkan diri Anda sebagai kolaborator repositori. Alur tidak dapat melihat anggota organisasi privat kecuali mereka adalah kolaborator langsung atau milik tim yang merupakan kolaborator langsung. Anda dapat mengubah keanggotaan organisasi GitHub dari privat ke publik di sini (ganti Your-Organization dengan nama organisasi Anda): https://github.com/orgs/Your-Organization/people.

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.

Selesai

Saat alur dipicu, Azure Pipelines menarik kode sumber Anda dari repositori Azure Repos Git. Anda dapat mengontrol berbagai aspek tentang bagaimana hal ini terjadi.

Catatan

Saat Anda menyertakan langkah checkout di alur Anda, kami menjalankan perintah berikut: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Jika ini tidak memenuhi kebutuhan Anda, Anda dapat memilih untuk mengecualikan checkout bawaan dengan checkout: none lalu menggunakan tugas skrip untuk melakukan checkout Anda sendiri.

Versi Git pilihan

Agen Windows dilengkapi dengan salinan Git sendiri. Jika Anda lebih suka menyediakan Git Anda sendiri daripada menggunakan salinan yang disertakan, atur System.PreferGitFromPath ke true. Pengaturan ini selalu benar pada agen non-Windows.

Jalur checkout

Jika Anda memeriksa satu repositori, secara default, kode sumber Anda akan dicek keluar ke direktori yang disebut s. Untuk alur YAML, Anda dapat mengubah ini dengan menentukan checkout dengan path. Jalur yang ditentukan relatif terhadap $(Agent.BuildDirectory). Misalnya: jika nilai jalur checkout adalah mycustompath dan $(Agent.BuildDirectory) adalah C:\agent\_work\1, maka kode sumber akan dicek keluar ke .C:\agent\_work\1\mycustompath

Jika Anda menggunakan beberapa checkout langkah dan memeriksa beberapa repositori, dan tidak secara eksplisit menentukan folder menggunakan path, setiap repositori ditempatkan dalam subfolder bernama s setelah repositori. Misalnya jika Anda memeriksa dua repositori bernama tools dan code, kode sumber akan diperiksa ke dalam C:\agent\_work\1\s\tools dan C:\agent\_work\1\s\code.

Harap dicatat bahwa nilai jalur checkout tidak dapat diatur untuk naik tingkat direktori apa pun di atas $(Agent.BuildDirectory), jadi path\..\anotherpath akan menghasilkan jalur checkout yang valid (yaitu C:\agent\_work\1\anotherpath), tetapi nilai seperti ..\invalidpath tidak akan (yaitu C:\agent\_work\invalidpath).

Anda dapat mengonfigurasi path pengaturan di langkah Checkout alur Anda.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Submodul

Anda dapat mengonfigurasi submodules pengaturan di langkah Checkout alur Anda jika Anda ingin mengunduh file dari submodul.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Alur build akan memeriksa submodul Git Anda selama:

  • Tidak diautentikasi: Repositori publik yang tidak diautentikasi tanpa kredensial yang diperlukan untuk mengkloning atau mengambil.

  • Dikonfirmasi:

    • Terkandung dalam proyek yang sama dengan repositori Azure Repos Git yang ditentukan di atas. Kredensial yang sama yang digunakan oleh agen untuk mendapatkan sumber dari repositori utama juga digunakan untuk mendapatkan sumber untuk submodul.

    • Ditambahkan dengan menggunakan URL relatif terhadap repositori utama. Misalnya

      • Yang satu ini akan diperiksa: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        Dalam contoh ini, submodul mengacu pada repositori (FabrikamFiber) di organisasi Azure DevOps yang sama, tetapi dalam proyek yang berbeda (FabrikamFiberProject). Kredensial yang sama yang digunakan oleh agen untuk mendapatkan sumber dari repositori utama juga digunakan untuk mendapatkan sumber untuk submodul. Ini mengharuskan token akses pekerjaan memiliki akses ke repositori di proyek kedua. Jika Anda membatasi token akses pekerjaan seperti yang dijelaskan di bagian di atas, maka Anda tidak akan dapat melakukan ini. Anda dapat mengizinkan token akses pekerjaan untuk mengakses repositori di proyek kedua dengan memberikan akses secara eksplisit ke akun layanan build proyek di proyek kedua atau (b) menggunakan token akses cakupan koleksi alih-alih token yang dicakup proyek untuk seluruh organisasi. Untuk informasi selengkapnya tentang opsi ini dan implikasi keamanannya, lihat Mengakses repositori, artefak, dan sumber daya lainnya.

      • Yang satu ini tidak akan diperiksa: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternatif untuk menggunakan opsi Submodul Checkout

Dalam beberapa kasus, Anda tidak dapat menggunakan opsi Submodul Checkout. Anda mungkin memiliki skenario di mana sekumpulan kredensial yang berbeda diperlukan untuk mengakses submodul. Ini dapat terjadi, misalnya, jika repositori utama dan repositori submodul Anda tidak disimpan di organisasi Azure DevOps yang sama, atau jika token akses pekerjaan Anda tidak memiliki akses ke repositori dalam proyek yang berbeda.

Jika Anda tidak dapat menggunakan opsi Submodul Checkout, maka Anda dapat menggunakan langkah skrip kustom untuk mengambil submodul. Pertama, dapatkan token akses pribadi (PAT) dan awali dengan pat:. Selanjutnya, base64-encode string awalan ini untuk membuat token autentikasi dasar. Terakhir, tambahkan skrip ini ke alur Anda:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Pastikan untuk mengganti "<BASE64_ENCODED_STRING>" dengan string "pat:token" yang dikodekan Base64 Anda.

Gunakan variabel rahasia dalam proyek Anda atau buat alur untuk menyimpan token autentikasi dasar yang Anda buat. Gunakan variabel tersebut untuk mengisi rahasia dalam perintah Git di atas.

Catatan

T: Mengapa saya tidak dapat menggunakan manajer kredensial Git pada agen?A: Menyimpan kredensial submodul di manajer kredensial Git yang diinstal pada agen build privat Anda biasanya tidak efektif karena manajer kredensial dapat meminta Anda untuk memasukkan kembali kredensial setiap kali submodul diperbarui. Ini tidak diinginkan selama build otomatis saat interaksi pengguna tidak dimungkinkan.

Sinkronkan tag

Penting

Fitur tag sinkronisasi didukung di Azure Repos Git dengan Azure DevOps Server 2022.1 dan yang lebih tinggi.

Langkah checkout menggunakan --tags opsi saat mengambil konten repositori Git. Hal ini menyebabkan server mengambil semua tag serta semua objek yang ditujukkan oleh tag tersebut. Ini meningkatkan waktu untuk menjalankan tugas dalam alur, terutama jika Anda memiliki repositori besar dengan sejumlah tag. Selain itu, langkah checkout menyinkronkan tag bahkan ketika Anda mengaktifkan opsi pengambilan dangkal, sehingga mungkin mengalahkan tujuannya. Untuk mengurangi jumlah data yang diambil atau ditarik dari repositori Git, Microsoft telah menambahkan opsi baru untuk checkout guna mengontrol perilaku sinkronisasi tag. Opsi ini tersedia baik dalam alur klasik maupun YAML.

Apakah akan menyinkronkan tag saat memeriksa repositori dapat dikonfigurasi di YAML dengan mengatur fetchTags properti, dan di UI dengan mengonfigurasi pengaturan Sinkronkan tag .

Anda dapat mengonfigurasi fetchTags pengaturan di langkah Checkout alur Anda.

Untuk mengonfigurasi pengaturan di YAML, atur fetchTags properti .

steps:
- checkout: self
  fetchTags: true

Anda juga dapat mengonfigurasi pengaturan ini dengan menggunakan opsi Sinkronkan tag di antarmuka pengguna pengaturan alur.

  1. Edit alur YAML Anda dan pilih Tindakan lainnya, Pemicu.

    Screenshot of more triggers menu.

  2. Pilih YAML, Dapatkan sumber.

    Screenshot of Get sources.

  3. Konfigurasikan pengaturan Sinkronkan tag.

    Screenshot of Sync tags setting.

Catatan

Jika Anda secara eksplisit mengatur fetchTags langkah Anda checkout , pengaturan tersebut lebih diprioritaskan daripada pengaturan yang dikonfigurasi di antarmuka pengguna pengaturan alur.

Perilaku default

  • Untuk alur yang ada yang dibuat sebelum rilis Azure DevOps sprint 209, dirilis pada Bulan September 2022, default untuk menyinkronkan tag tetap sama dengan perilaku yang ada sebelum opsi Sinkronkan tag ditambahkan, yaitu true.
  • Untuk alur baru yang dibuat setelah rilis sprint Azure DevOps 209, default untuk menyinkronkan tag adalah false.

Catatan

Jika Anda secara eksplisit mengatur fetchTags langkah Anda checkout , pengaturan tersebut lebih diprioritaskan daripada pengaturan yang dikonfigurasi di antarmuka pengguna pengaturan alur.

Pengambilan dangkal

Anda mungkin ingin membatasi seberapa jauh ke belakang dalam riwayat untuk diunduh. Secara efektif ini menghasilkan git fetch --depth=n. Jika repositori Anda besar, opsi ini mungkin membuat alur build Anda lebih efisien. Repositori Anda mungkin besar jika telah digunakan untuk waktu yang lama dan memiliki riwayat yang cukup besar. Ini juga mungkin besar jika Anda menambahkan dan kemudian menghapus file besar.

Penting

Alur baru yang dibuat setelah pembaruan Azure DevOps sprint 209 September 2022 memiliki pengambilan Shallow yang diaktifkan secara default dan dikonfigurasi dengan kedalaman 1. Sebelumnya defaultnya adalah tidak mengambil dangkal. Untuk memeriksa alur Anda, lihat pengaturan Pengambilan dangkal di antarmuka pengguna pengaturan alur seperti yang dijelaskan di bagian berikut.

Anda dapat mengonfigurasi fetchDepth pengaturan di langkah Checkout alur Anda.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Anda juga dapat mengonfigurasi kedalaman pengambilan dengan mengatur opsi Kedalaman Dangkal di antarmuka pengguna pengaturan alur.

  1. Edit alur YAML Anda dan pilih Tindakan lainnya, Pemicu.

    Screenshot of more triggers menu.

  2. Pilih YAML, Dapatkan sumber.

    Screenshot of Get sources.

  3. Konfigurasikan pengaturan pengambilan Shallow. Hapus centang Pengambilan dangkal untuk menonaktifkan pengambilan dangkal, atau centang kotak dan masukkan Kedalaman untuk mengaktifkan pengambilan dangkal.

    Screenshot of options.

Catatan

Jika Anda secara eksplisit mengatur fetchDepth langkah Anda checkout , pengaturan tersebut lebih diprioritaskan daripada pengaturan yang dikonfigurasi di antarmuka pengguna pengaturan alur. Pengaturan fetchDepth: 0 mengambil semua riwayat dan mengambil alih pengaturan pengambilan Dangkal.

Dalam kasus ini, opsi ini dapat membantu Anda menghemat sumber daya jaringan dan penyimpanan. Ini mungkin juga menghemat waktu. Alasannya tidak selalu menghemat waktu adalah karena dalam beberapa situasi server mungkin perlu menghabiskan waktu menghitung penerapan untuk mengunduh kedalaman yang Anda tentukan.

Catatan

Ketika alur dimulai, cabang yang akan dibangun diselesaikan ke ID penerapan. Kemudian, agen mengambil cabang dan memeriksa penerapan yang diinginkan. Ada jendela kecil antara ketika cabang diselesaikan ke ID penerapan dan ketika agen melakukan pembayaran. Jika cabang diperbarui dengan cepat dan Anda menetapkan nilai yang sangat kecil untuk pengambilan dangkal, penerapan mungkin tidak ada ketika agen mencoba untuk memeriksanya. Jika itu terjadi, tingkatkan pengaturan kedalaman pengambilan dangkal.

Jangan sinkronkan sumber

Anda mungkin ingin melewati pengambilan penerapan baru. Opsi ini dapat berguna jika Anda ingin:

  • Git init, konfigurasi, dan ambil menggunakan opsi kustom Anda sendiri.

  • Gunakan alur build untuk hanya menjalankan otomatisasi (misalnya beberapa skrip) yang tidak bergantung pada kode dalam kontrol versi.

Anda dapat mengonfigurasi pengaturan Jangan sinkronkan sumber di langkah Checkout alur Anda, dengan mengatur checkout: none.

steps:
- checkout: none  # Don't sync sources

Catatan

Saat Anda menggunakan opsi ini, agen juga melompati menjalankan perintah Git yang membersihkan repositori.

Bersihkan build

Anda dapat melakukan berbagai bentuk pembersihan direktori kerja agen yang dihost sendiri sebelum build berjalan.

Secara umum, untuk performa agen yang dihost sendiri lebih cepat, jangan bersihkan repositori. Dalam hal ini, untuk mendapatkan performa terbaik, pastikan Anda juga membangun secara bertahap dengan menonaktifkan opsi Bersih dari tugas atau alat yang Anda gunakan untuk membangun.

Jika Anda perlu membersihkan repositori (misalnya untuk menghindari masalah yang disebabkan oleh file residu dari build sebelumnya), opsi Anda berada di bawah ini.

Catatan

Pembersihan tidak efektif jika Anda menggunakan agen yang dihosting Microsoft karena Anda akan mendapatkan agen baru setiap saat.

Anda dapat mengonfigurasi clean pengaturan di langkah Checkout alur Anda.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Ketika clean diatur ke true alur build melakukan pengurungan perubahan apa pun di $(Build.SourcesDirectory). Lebih khusus lagi, perintah Git berikut dijalankan sebelum mengambil sumbernya.

git clean -ffdx
git reset --hard HEAD

Untuk opsi lainnya, Anda dapat mengonfigurasi workspace pengaturan Pekerjaan.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Ini memberikan opsi bersih berikut.

  • output: Operasi yang sama dengan pengaturan bersih yang dijelaskan dalam tugas checkout sebelumnya, ditambah: Menghapus dan membuat $(Build.BinariesDirectory)ulang . Perhatikan bahwa $(Build.ArtifactStagingDirectory) dan $(Common.TestResultsDirectory) selalu dihapus dan dibuat ulang sebelum setiap build terlepas dari salah satu pengaturan ini.

  • sumber daya: Menghapus dan membuat $(Build.SourcesDirectory)ulang . Ini menghasilkan inisialisasi repositori Git lokal baru untuk setiap build.

  • all: Menghapus dan membuat $(Agent.BuildDirectory)ulang . Ini menghasilkan inisialisasi repositori Git lokal baru untuk setiap build.

Sumber label

Anda mungkin ingin memberi label file kode sumber untuk memungkinkan tim Anda dengan mudah mengidentifikasi versi mana dari setiap file yang disertakan dalam build yang telah selesai. Anda juga memiliki opsi untuk menentukan apakah kode sumber harus diberi label untuk semua build atau hanya untuk build yang berhasil.

Saat ini Anda tidak dapat mengonfigurasi pengaturan ini di YAML tetapi Anda dapat berada di editor klasik. Saat mengedit alur YAML, Anda dapat mengakses editor klasik dengan memilih Salah satu Pemicu dari menu editor YAML.

Configure Git options, YAML.

Dari editor klasik, pilih YAML, pilih tugas Dapatkan sumber , lalu konfigurasikan properti yang diinginkan di sana.

From the Classic editor, choose YAML > Get sources.

Dalam format Tag, Anda dapat menggunakan variabel yang ditentukan pengguna dan ditentukan sebelumnya yang memiliki cakupan "Semua." Misalnya:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Empat variabel pertama telah ditentukan sebelumnya. My.Variable dapat ditentukan oleh Anda pada tab variabel.

Alur build memberi label sumber Anda dengan tag Git.

Beberapa variabel build mungkin menghasilkan nilai yang bukan label yang valid. Misalnya, variabel seperti $(Build.RequestedFor) dan $(Build.DefinitionName) dapat berisi spasi kosong. Jika nilai berisi spasi kosong, tag tidak dibuat.

Setelah sumber ditandai oleh alur build Anda, artefak dengan Git ref refs/tags/{tag} secara otomatis ditambahkan ke build yang telah selesai. Ini memberi tim Anda keterlacakan tambahan dan cara yang lebih ramah pengguna untuk menavigasi dari build ke kode yang dibangun. Tag dianggap sebagai artefak build karena diproduksi oleh build. Saat build dihapus baik secara manual atau melalui kebijakan penyimpanan, tag juga dihapus.

Variabel yang telah ditentukan sebelumnya

Saat Anda membangun repositori GitHub, sebagian besar variabel yang telah ditentukan tersedia untuk pekerjaan Anda. Namun, karena Azure Pipelines tidak mengenali identitas pengguna yang membuat pembaruan di GitHub, variabel berikut diatur ke identitas sistem alih-alih identitas pengguna:

  • Build.RequestedFor
  • Build.RequestedForId
  • Build.RequestedForEmail

Pembaruan status

Ada dua jenis status yang diposting Azure Pipelines kembali ke GitHub - status dasar dan GitHub Check Runs. Fungsionalitas Pemeriksaan GitHub hanya tersedia dengan Aplikasi GitHub.

Status alur muncul di berbagai tempat di antarmuka pengguna GitHub.

  • Untuk PR, mereka ditampilkan di tab percakapan PR.
  • Untuk penerapan individual, penerapan ditampilkan saat mengarahkan kuartal ke tanda status setelah waktu penerapan pada tab penerapan repositori.

Koneksi PAT atau OAuth GitHub

Untuk alur yang menggunakan koneksi PAT atau OAuth GitHub, status diposting kembali ke commit/PR yang memicu eksekusi. API status GitHub digunakan untuk memposting pembaruan tersebut. Status ini berisi informasi terbatas: status alur (gagal, berhasil), URL untuk menautkan kembali ke alur build, dan deskripsi singkat tentang status.

Status untuk koneksi PAT atau OAuth GitHub hanya dikirim pada tingkat eksekusi. Dengan kata lain, Anda dapat memiliki satu status yang diperbarui untuk seluruh proses. Jika Anda memiliki beberapa pekerjaan dalam proses, Anda tidak dapat memposting status terpisah untuk setiap pekerjaan. Namun, beberapa alur dapat memposting status terpisah ke penerapan yang sama.

Pemeriksaan GitHub

Untuk alur yang disiapkan menggunakan aplikasi Azure Pipelines GitHub, status diposting kembali dalam bentuk GitHub Checks. Pemeriksaan GitHub memungkinkan pengiriman informasi terperinci tentang status alur dan pengujian, cakupan kode, dan kesalahan. GITHub Checks API dapat ditemukan di sini.

Untuk setiap alur yang menggunakan Aplikasi GitHub, Pemeriksaan diposting kembali untuk eksekusi keseluruhan dan setiap pekerjaan dalam eksekusi tersebut.

GitHub memungkinkan tiga opsi ketika satu atau beberapa Eksekusi Pemeriksaan gagal untuk PR/commit. Anda dapat memilih untuk "menjalankan ulang" Masing-masing Pemeriksaan, menjalankan ulang semua Pemeriksaan yang gagal pada PR/penerapan tersebut, atau menjalankan ulang semua Pemeriksaan, apakah mereka berhasil awalnya atau tidak.

GitHub checks rerun

Mengklik tautan "Jalankan ulang" di samping nama Periksa Eksekusi akan mengakibatkan Azure Pipelines mencoba kembali eksekusi yang menghasilkan Check Run. Eksekusi yang dihasilkan akan memiliki nomor eksekusi yang sama dan akan menggunakan versi kode sumber, konfigurasi, dan file YAML yang sama dengan build awal. Hanya pekerjaan yang gagal dalam eksekusi awal dan pekerjaan hilir dependen apa pun yang akan dijalankan lagi. Mengklik tautan "Jalankan ulang semua pemeriksaan yang gagal" akan memiliki efek yang sama. Ini adalah perilaku yang sama dengan mengklik "Coba lagi jalankan" di antarmuka pengguna Azure Pipelines. Mengklik "Jalankan ulang semua pemeriksaan" akan menghasilkan eksekusi baru, dengan nomor eksekusi baru dan akan mengambil perubahan dalam konfigurasi atau file YAML.

Pembatasan

  • Untuk performa terbaik, kami merekomendasikan maksimal 50 alur dalam satu repositori. Untuk performa yang dapat diterima, kami merekomendasikan maksimum 100 alur dalam satu repositori. Waktu yang diperlukan untuk memproses dorongan ke repositori meningkat dengan jumlah alur di repositori tersebut. Setiap kali ada dorongan ke repositori, Azure Pipelines perlu memuat semua alur YAML di repositori tersebut untuk mencari tahu apakah salah satu dari mereka perlu dijalankan, dan memuat setiap alur dikenakan penalti performa. Selain masalah performa, memiliki terlalu banyak alur dalam satu repositori dapat menyebabkan pembatasan di sisi GitHub, karena Azure Pipelines mungkin membuat terlalu banyak permintaan dalam waktu singkat.
  • Penggunaan perluasan dan menyertakan templat dalam alur berdampak pada tingkat di mana Azure Pipelines membuat permintaan API GitHub dan dapat menyebabkan pembatasan di sisi GitHub. Sebelum menjalankan alur, Azure Pipelines perlu menghasilkan kode YAML lengkap, sehingga perlu mengambil semua file templat.
  • 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 GitHub termasuk dalam kategori berikut:

  • jenis Koneksi ion: Saya tidak yakin jenis koneksi apa yang saya gunakan untuk menyambungkan alur saya ke GitHub.
  • Pemicu yang gagal: Alur saya tidak dipicu saat saya mendorong pembaruan ke repositori.
  • Gagal checkout: Alur saya sedang dipicu, tetapi gagal di langkah checkout.
  • Versi yang salah: Alur saya berjalan, tetapi menggunakan versi sumber/YAML yang tidak terduga.
  • Pembaruan status hilang: PR GitHub saya diblokir karena Azure Pipelines tidak melaporkan pembaruan status.

Jenis koneksi

Untuk memecahkan masalah pemicu, bagaimana cara mengetahui jenis koneksi GitHub yang saya gunakan untuk alur saya?

Pemecahan masalah dengan pemicu sangat tergantung pada jenis koneksi GitHub yang Anda gunakan di alur Anda. Ada dua cara untuk menentukan jenis koneksi - dari GitHub dan dari Azure Pipelines.

  • Dari GitHub: Jika repo disiapkan untuk menggunakan aplikasi GitHub, maka status pada PR dan penerapannya adalah Check Runs. Jika repositori memiliki Azure Pipelines yang disiapkan dengan koneksi OAuth atau PAT, statusnya akan menjadi gaya status "lama". Cara cepat untuk menentukan apakah statusnya adalah Periksa Eksekusi atau status sederhana adalah dengan melihat tab "percakapan" pada GitHub PR.

    • Jika tautan "Detail" dialihkan ke tab Pemeriksaan, tautan tersebut adalah Check Run dan repositori menggunakan aplikasi.
    • Jika tautan "Detail" dialihkan ke alur Azure DevOps, maka statusnya adalah status "gaya lama" dan repositori tidak menggunakan aplikasi.

  • Dari Azure Pipelines: Anda juga dapat menentukan jenis koneksi dengan memeriksa alur di antarmuka pengguna Azure Pipelines. Buka editor untuk alur. Pilih Pemicu untuk membuka editor klasik untuk alur. Kemudian, pilih tab YAML lalu langkah Dapatkan sumber . Anda akan melihat banner Diotorisasi menggunakan koneksi: menunjukkan koneksi layanan yang digunakan untuk mengintegrasikan alur dengan GitHub. Nama koneksi layanan adalah hyperlink. Pilih untuk menavigasi ke properti koneksi layanan. Properti koneksi layanan akan menunjukkan jenis koneksi yang digunakan:

    • Aplikasi Azure Pipelines menunjukkan koneksi aplikasi GitHub
    • oauth menunjukkan koneksi OAuth
    • personalaccesstoken menunjukkan autentikasi PAT

Bagaimana cara mengalihkan alur saya untuk menggunakan aplikasi GitHub alih-alih OAuth?

Menggunakan aplikasi GitHub alih-alih koneksi OAuth atau PAT adalah integrasi yang direkomendasikan antara GitHub dan Azure Pipelines. Untuk beralih ke aplikasi GitHub, ikuti langkah-langkah berikut:

  1. Buka di sini dan instal aplikasi di organisasi GitHub repositori Anda.
  2. Selama penginstalan, Anda akan diarahkan ke Azure DevOps untuk memilih organisasi dan proyek Azure DevOps. Pilih organisasi dan proyek yang berisi alur build klasik yang ingin Anda gunakan aplikasinya. Pilihan ini mengaitkan penginstalan Aplikasi GitHub dengan organisasi Azure DevOps Anda. Jika Anda salah memilih, Anda dapat mengunjungi halaman ini untuk menghapus instalan aplikasi GitHub dari organisasi GitHub Anda dan memulai kembali.
  3. Di halaman berikutnya yang muncul, Anda tidak perlu melanjutkan membuat alur baru.
  4. Edit alur Anda dengan mengunjungi halaman Alur (misalnya, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), memilih alur Anda, dan mengklik Edit.
  5. Jika ini adalah alur YAML, pilih menu Pemicu untuk membuka editor klasik.
  6. Pilih langkah "Dapatkan sumber" di alur.
  7. Pada bilah hijau dengan teks "Diotorisasi menggunakan koneksi", pilih "Ubah" dan pilih koneksi Aplikasi GitHub dengan nama yang sama dengan organisasi GitHub tempat Anda menginstal aplikasi.
  8. Pada toolbar, pilih "Simpan dan antrean" lalu "Simpan dan antrean". Pilih tautan ke eksekusi alur yang diantrekan untuk memastikannya berhasil.
  9. Buat (atau tutup dan buka kembali) permintaan pull di repositori GitHub Anda untuk memverifikasi bahwa build berhasil diantrekan di bagian "Pemeriksaan".

Mengapa repositori GitHub tidak ditampilkan bagi saya untuk dipilih di Azure Pipelines?

Bergantung pada jenis autentikasi dan kepemilikan repositori, izin tertentu diperlukan.

  • Jika Anda menggunakan Aplikasi GitHub, lihat Autentikasi Aplikasi GitHub.
  • Jika Anda menggunakan OAuth, lihat Autentikasi OAuth.
  • Jika Anda menggunakan PATs, lihat Autentikasi token akses pribadi (PAT).

Saat saya memilih repositori selama pembuatan alur, saya mendapatkan kesalahan "Repositori {repo-name} sedang digunakan dengan Aplikasi Azure Pipelines GitHub di organisasi Azure DevOps lain."

Ini berarti bahwa repositori Anda sudah dikaitkan dengan alur di organisasi yang berbeda. Peristiwa CI dan PR dari repositori ini tidak akan berfungsi karena akan dikirimkan ke organisasi lain. Berikut adalah langkah-langkah yang harus Anda ambil untuk menghapus pemetaan ke organisasi lain sebelum melanjutkan untuk membuat alur.

  1. Buka permintaan pull di repositori GitHub Anda, dan buat komentar /azp where. Ini melaporkan kembali organisasi Azure DevOps tempat repositori dipetakan.

  2. Untuk mengubah pemetaan, hapus instalan aplikasi dari organisasi GitHub, dan instal ulang. Saat Anda menginstal ulang, pastikan untuk memilih organisasi yang benar saat Anda dialihkan ke Azure DevOps.

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.

  • Apakah Anda menggunakan koneksi aplikasi GitHub untuk menyambungkan alur ke GitHub? Lihat jenis Koneksi ion untuk menentukan jenis koneksi yang Anda miliki. Jika Anda menggunakan koneksi aplikasi GitHub, ikuti langkah-langkah berikut:

    • Apakah pemetaan disiapkan dengan benar antara GitHub dan Azure DevOps? Buka permintaan pull di repositori GitHub Anda, dan buat komentar /azp where. Ini melaporkan kembali organisasi Azure DevOps tempat repositori dipetakan.

      • Jika tidak ada organisasi yang disiapkan untuk membangun repositori ini menggunakan aplikasi, buka https://github.com/<org_name>/<repo_name>/settings/installations dan selesaikan konfigurasi aplikasi.

      • Jika organisasi Azure DevOps yang berbeda dilaporkan, maka seseorang telah membuat alur untuk repositori ini di organisasi yang berbeda. Saat ini kami memiliki batasan bahwa kami hanya dapat memetakan repositori GitHub ke satu org DevOps. Hanya alur di org Azure DevOps pertama yang dapat dipicu secara otomatis. Untuk mengubah pemetaan, hapus instalan aplikasi dari organisasi GitHub, dan instal ulang. Saat Anda menginstal ulang, pastikan untuk memilih organisasi yang benar saat Anda dialihkan ke Azure DevOps.

  • Apakah Anda menggunakan OAuth atau PAT untuk menyambungkan alur ke GitHub? Lihat jenis Koneksi ion untuk menentukan jenis koneksi yang Anda miliki. Jika Anda menggunakan koneksi GitHub, ikuti langkah-langkah berikut:

    1. Koneksi OAuth dan PAT mengandalkan webhook untuk mengomunikasikan pembaruan ke Azure Pipelines. Di GitHub, navigasikan ke pengaturan untuk repositori Anda, lalu ke Webhooks. Verifikasi bahwa webhook ada. Biasanya Anda akan melihat tiga webhook - dorong, pull_request, dan issue_comment. Jika tidak, maka Anda harus membuat ulang koneksi layanan dan memperbarui alur untuk menggunakan koneksi layanan baru.

    2. Pilih masing-masing webhook di GitHub dan verifikasi bahwa payload yang sesuai dengan penerapan pengguna ada dan berhasil dikirim ke Azure DevOps. Anda mungkin melihat kesalahan di sini jika peristiwa tidak dapat dikomunikasikan ke Azure DevOps.

  • Lalu lintas dari Azure DevOps dapat dibatasi oleh GitHub. Saat Azure Pipelines menerima pemberitahuan dari GitHub, Azure Pipelines mencoba menghubungi GitHub dan mengambil informasi selengkapnya tentang file repositori dan YAML. Jika Anda memiliki repositori dengan sejumlah besar pembaruan dan permintaan pull, panggilan ini mungkin gagal karena pembatasan tersebut. Dalam hal ini, lihat apakah Anda dapat mengurangi frekuensi build dengan menggunakan filter batching atau jalur/cabang yang lebih ketat.

  • 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, ikuti langkah-langkah pemecahan masalah dalam pertanyaan sebelumnya, lalu 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 penundaan 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. Berikut adalah beberapa alasan mengapa penundaan mungkin terjadi:

    • 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.
    • Repositori Anda berisi terlalu banyak alur YAML. Untuk performa terbaik, kami merekomendasikan maksimal 50 alur dalam satu repositori. Untuk performa yang dapat diterima, kami merekomendasikan maksimum 100 alur dalam satu repositori. Semakin banyak alur, semakin lambat pemrosesan dorongan ke repositori tersebut. Setiap kali ada pendorongan ke repositori, Azure Pipelines perlu memuat semua alur YAML di repositori tersebut, untuk mencari tahu apakah salah satu dari mereka perlu dijalankan, dan setiap alur baru dikenakan hukuman performa.

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.

Gagal checkout

Saya melihat kesalahan berikut dalam file log selama langkah checkout. Bagaimana saya memperbaikinya?

remote: Repository not found.
fatal: repository <repo> not found

Ini bisa disebabkan oleh pemadaman GitHub. Cobalah untuk mengakses repositori di GitHub dan pastikan Anda dapat melakukannya.

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.

Pembaruan status hilang

PR saya di GitHub diblokir karena Azure Pipelines tidak memperbarui status.

Ini bisa menjadi kesalahan sementara yang mengakibatkan Azure DevOps tidak dapat berkomunikasi dengan GitHub. Coba lagi GitHub check-in jika Anda menggunakan aplikasi GitHub. Atau, buat pembaruan sepele ke PR untuk melihat apakah masalah dapat diselesaikan.