Membangun repositori Git Azure Repos atau TFS Git

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

Azure Pipelines dapat secara otomatis membangun dan memvalidasi setiap permintaan pull dan berkomitmen ke repositori Azure Repos Git Anda.

Pilih repositori yang akan dibangun

YAML

Anda membuat alur baru dengan terlebih dahulu memilih repositori 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.

Klasik

Saat membuat alur, untuk memilih repositori yang akan dibangun, pertama-tama pilih proyek tempat repositori berada. Kemudian, pilih repositori.

Untuk mengkloning repositori tambahan sebagai bagian dari alur Anda:

• Jika repositori berada dalam proyek yang sama dengan alur Anda, atau jika token akses (dijelaskan di bawah) memiliki akses ke repositori dalam proyek yang berbeda, gunakan perintah berikut:

  git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" <clone URL>

  Untuk menggunakan System.AccessToken dalam skrip, Anda harus terlebih dahulu membuatnya tersedia untuk skrip. Untuk melakukan ini, pilih pekerjaan di bawah tab Tugas di editor, pilih Opsi Tambahan di panel kanan, dan centang opsi untuk Mengizinkan skrip mengakses token OAuth.

• Jika token akses (dijelaskan di bawah) tidak memiliki akses ke repositori:

  1. Dapatkan token akses pribadi (PAT) dengan Code (read) cakupan, dan awali denganPAT:
  2. Base64-encode string ini untuk membuat token autentikasi dasar.
  3. Tambahkan skrip di alur Anda dengan perintah berikut untuk mengkloning repositori tersebut git clone -c http.extraheader="AUTHORIZATION: basic <BASIC_AUTH_TOKEN>" <clone URL>

Azure Pipelines harus diberikan akses ke repositori Anda untuk memicu build mereka dan mengambil kode mereka selama build. Biasanya, alur memiliki akses ke repositori dalam proyek yang sama. Tetapi, jika Anda ingin mengakses repositori dalam proyek yang berbeda, maka Anda perlu memperbarui izin yang diberikan ke token akses pekerjaan.

Pemicu CI

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

YAML

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.

Klasik

Pilih Aktifkan integrasi berkelanjutan pada tab Pemicu untuk mengaktifkan pemicu ini jika Anda ingin build berjalan setiap kali seseorang memeriksa kode.

Perubahan batch

Pilih kotak centang ini jika Anda sering memiliki banyak anggota tim yang sering mengunggah perubahan dan Anda ingin mengurangi jumlah build yang Anda jalankan. Jika Anda memilih opsi ini, saat build berjalan, sistem menunggu hingga eksekusi selesai dan kemudian mengantrekan eksekusi lain dari semua perubahan yang belum dibuat.

Anda dapat membuat batch perubahan dan membangunnya bersama-sama.

Catatan

Jika Anda menggunakan batching dengan alur YAML multi-tahap, eksekusi harus mencapai status terminal sebelum yang berikutnya dapat dimulai. Ini sering tidak diinginkan karena alur multi-tahap dapat melalui persetujuan dan tahap penyebaran yang berjalan lama. Dalam kasus ini, disarankan agar Anda mengikuti salah satu solusi ini:

• jangan gunakan batching
• membagi alur menjadi dua alur terpisah - satu untuk CI dan satu CD
• atur kondisi yang sesuai pada tahapan untuk melewatinya dan membuat eksekusi berakhir dengan cepat

Filter cabang

Anda dapat menentukan cabang tempat Anda ingin memicu build. Jika Anda ingin menggunakan karakter kartubebas, ketik spesifikasi cabang (misalnya, features/modules/*) lalu tekan Enter.

Filter jalur

Jika repositori Git Anda berada di Azure Repos atau TFS, Anda juga dapat menentukan filter jalur untuk mengurangi kumpulan file yang ingin Anda picu build.

Tips:

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

Contoh

Misalnya, Anda ingin build Anda dipicu oleh perubahan di main dan sebagian besar, tetapi tidak semua, dari cabang fitur Anda. Anda juga tidak ingin build dipicu oleh perubahan pada file di folder alat.

Melompati CI untuk dorongan 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 Anda membuka permintaan pull, atau saat Anda mendorong perubahan padanya. Di Azure Repos Git, fungsionalitas ini diterapkan menggunakan kebijakan cabang. Untuk mengaktifkan validasi PR, navigasikan ke kebijakan cabang untuk cabang yang diinginkan, dan konfigurasikan kebijakan validasi Build untuk cabang tersebut. Untuk informasi selengkapnya, lihat Mengonfigurasi kebijakan cabang.

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

• Alur yang ditentukan oleh kebijakan validasi build cabang target 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, bahkan jika beberapa pesan atau deskripsi penerapan gabungan berisi [skip ci] (atau variannya).

Catatan

Untuk mengonfigurasi build validasi untuk repositori Azure Repos Git, Anda harus menjadi administrator proyek proyeknya.

Catatan

Draf permintaan pull tidak memicu alur meskipun Anda mengonfigurasi kebijakan cabang.

Memvalidasi kontribusi dari fork

Membangun permintaan pull dari azure Repos forks tidak berbeda dengan membangun permintaan pull dalam repositori atau proyek yang sama. Anda hanya dapat membuat fork dalam organisasi yang sama dengan bagian proyek Anda.

Membatasi cakupan otorisasi pekerjaan

Azure Pipelines menyediakan beberapa pengaturan keamanan untuk mengonfigurasi cakupan otorisasi pekerjaan yang dijalankan alur Anda.

• Membatasi cakupan otorisasi pekerjaan ke proyek saat ini
• Melindungi akses ke repositori di alur YAML

Membatasi cakupan otorisasi pekerjaan ke proyek saat ini

Azure Pipelines menyediakan dua cakupan otorisasi pekerjaan Batasi ke pengaturan proyek saat ini:

• Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis - Pengaturan ini berlaku untuk alur YAML dan alur build klasik. Pengaturan ini tidak berlaku untuk alur rilis klasik.
• Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur rilis - Pengaturan ini hanya berlaku untuk alur rilis klasik.

Alur berjalan dengan token akses terlingkup koleksi kecuali pengaturan yang relevan untuk jenis alur diaktifkan. Pengaturan Batasi cakupan otorisasi pekerjaan memungkinkan Anda mengurangi cakupan akses untuk semua alur ke proyek saat ini. Ini dapat memengaruhi alur Anda jika Anda mengakses repositori Azure Repos Git dalam proyek yang berbeda di organisasi Anda.

Jika repositori Azure Repos Git Anda berada dalam proyek yang berbeda dari alur Anda, dan pengaturan Batasi cakupan otorisasi pekerjaan untuk jenis alur Anda diaktifkan, Anda harus memberikan izin ke identitas layanan build untuk alur Anda ke proyek kedua. Untuk informasi selengkapnya, lihat Mengelola izin akun layanan build.

Untuk informasi selengkapnya tentang Membatasi cakupan otorisasi pekerjaan, lihat Memahami token akses pekerjaan.

Melindungi akses ke repositori di alur YAML

Alur dapat mengakses repositori Azure DevOps apa pun dalam proyek resmi, seperti yang dijelaskan dalam bagian Batasi otorisasi pekerjaan sebelumnya ke proyek saat ini, kecuali jika Lindungi akses ke repositori di alur YAML diaktifkan. Dengan opsi ini diaktifkan, Anda dapat mengurangi cakupan akses untuk semua alur menjadi hanya repositori Azure DevOps yang secara eksplisit direferensikan oleh checkout langkah atau uses pernyataan dalam pekerjaan alur yang menggunakan repositori tersebut.

Untuk mengonfigurasi pengaturan ini, navigasikan ke Alur, Pengaturan di pengaturan Organisasi atau pengaturan Proyek. Jika diaktifkan di tingkat organisasi, pengaturan berwarna abu-abu dan tidak tersedia di tingkat pengaturan proyek.

Penting

Lindungi akses ke repositori di alur YAML diaktifkan secara default untuk organisasi dan proyek baru yang dibuat setelah Mei 2020. Saat Lindungi akses ke repositori di alur YAML diaktifkan, alur YAML Anda harus secara eksplisit mereferensikan repositori Azure Repos Git apa pun yang ingin Anda gunakan dalam alur sebagai langkah checkout dalam pekerjaan yang menggunakan repositori. Anda tidak akan dapat mengambil kode menggunakan tugas pembuatan skrip dan perintah git untuk repositori Azure Repos Git kecuali repositori tersebut pertama kali direferensikan secara eksplisit.

Ada beberapa pengecualian di mana Anda tidak perlu secara eksplisit mereferensikan repositori Azure Repos Git sebelum menggunakannya di alur Anda saat Melindungi akses ke repositori di alur YAML diaktifkan.

• Jika Anda tidak memiliki langkah checkout eksplisit di alur Anda, itu seolah-olah Anda memiliki checkout: self langkah, dan self repositori dicek keluar.
• Jika Anda menggunakan skrip untuk melakukan operasi baca-saja pada repositori dalam proyek publik, Anda tidak perlu mereferensikan repositori proyek publik dalam satu checkout langkah.
• Jika Anda menggunakan skrip yang menyediakan autentikasinya sendiri ke repositori, seperti PAT, Anda tidak perlu mereferensikan repositori tersebut dalam langkah checkout .

Misalnya, saat Lindungi akses ke repositori di alur YAML diaktifkan, jika alur Anda berada di FabrikamProject/Fabrikam repositori di organisasi Anda, dan Anda ingin menggunakan skrip untuk memeriksa repositori FabrikamProject/FabrikamTools , Anda harus mereferensikan repositori ini dalam checkout langkah atau dengan uses pernyataan.

Jika Anda sudah memeriksa repositori FabrikamTools di alur Anda menggunakan langkah checkout, Anda kemudian dapat menggunakan skrip untuk berinteraksi dengan repositori tersebut.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Catatan

Untuk banyak skenario, checkout multi-repo dapat dimanfaatkan, menghapus kebutuhan untuk menggunakan skrip untuk memeriksa repositori tambahan di alur Anda. Untuk informasi selengkapnya, lihat Melihat beberapa repositori di alur Anda.

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

YAML

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

Klasik

Pengaturan ini tidak dapat dikonfigurasi di editor klasik. Kode sumber Anda akan diperiksa ke direktori yang disebut s, yang relatif terhadap $(Agent.BuildDirectory). Misalnya: jika $(Agent.BuildDirectory) adalah C:\agent\_work\1, maka kode sumber akan diperiksa ke dalam C:\agent\_work\1\mycustompath.

Submodul

YAML

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

Klasik

Anda dapat mengonfigurasi pengaturan Submodul dari properti tugas Dapatkan sumber di alur Anda jika Anda ingin mengunduh file dari submodul.

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 .

YAML

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.

   

2. Pilih YAML, Dapatkan sumber.

   

3. Konfigurasikan pengaturan Sinkronkan tag.

   

Catatan

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

Klasik

Anda dapat mengonfigurasi pengaturan Sinkronkan tag dari properti tugas Dapatkan sumber di alur Anda.

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.

YAML

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.

   

2. Pilih YAML, Dapatkan sumber.

   

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

   

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.

Klasik

Anda dapat mengonfigurasi pengaturan pengambilan Shallow dari properti tugas Dapatkan sumber di alur Anda.

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.

YAML

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

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

Klasik

Pilih pengaturan Jangan sinkronkan sumber dari properti tugas Dapatkan sumber di alur Anda.

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.

YAML

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.

Klasik

Pilih pengaturan Bersihkan dari properti tugas Dapatkan sumber di alur Anda dan pilih salah satu opsi berikut.

• Sumber: 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
  

• Sumber dan direktori output: Operasi yang sama dengan opsi Sumber di atas, 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.

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

• Semua direktori build: 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.

YAML

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.

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

Klasik

Anda dapat mengonfigurasi pengaturan Sumber tag dari properti tugas Dapatkan sumber di alur Anda.

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.

FAQ

Masalah yang terkait dengan integrasi Azure Repos termasuk dalam tiga kategori:

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

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.

  

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

  

• Apakah Anda mengonfigurasi pemicu PR dalam file YAML atau dalam kebijakan cabang untuk repositori? Untuk repositori Azure Repos Git, Anda tidak dapat mengonfigurasi pemicu PR dalam file YAML. Anda perlu menggunakan kebijakan cabang.

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

Saya memiliki beberapa repositori di alur YAML saya. Bagaimana cara menyiapkan pemicu untuk setiap repositori?

Lihat pemicu dalam Menggunakan beberapa repositori.

Gagal checkout

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

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

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

• Apakah repositori masih ada? Pertama, pastikan itu dilakukan dengan membukanya di halaman Repos .

• Apakah Anda mengakses repositori menggunakan skrip? Jika demikian, periksa batasi cakupan otorisasi pekerjaan ke pengaturan repositori Azure DevOps yang direferensikan. Saat Batasi cakupan otorisasi pekerjaan ke repositori Azure DevOps yang direferensikan diaktifkan, Anda tidak akan dapat memeriksa repositori Azure Repos Git menggunakan skrip kecuali repositori tersebut secara eksplisit direferensikan terlebih dahulu dalam alur.

• Apa cakupan otorisasi pekerjaan alur?

  • Jika cakupannya adalah koleksi:

    • Ini mungkin kesalahan terputus-terputus. Jalankan kembali alur.
    • Seseorang mungkin telah menghapus akses ke akun Project Collection Build Service.
      • Buka Pengaturan proyek untuk proyek tempat repositori berada. Pilih Repositori > repositori >tertentu, lalu Keamanan.
      • Periksa apakah Project Collection Build Service (nama koleksi Anda) ada dalam daftar pengguna.
      • Periksa apakah akun tersebut memiliki akses Buat tag dan Baca .

  • Jika cakupannya adalah proyek:

    • Apakah repositori dalam proyek yang sama dengan alur?
      • Ya:
        • Ini mungkin kesalahan terputus-terputus. Jalankan kembali alur.
        • Seseorang mungkin telah menghapus akses ke akun Project Build Service.
          • Buka Pengaturan proyek untuk proyek tempat repositori berada. Pilih Repositori > repositori >tertentu, lalu Keamanan.
          • Periksa apakah Nama proyek Anda Build Service (nama koleksi Anda) ada dalam daftar pengguna.
          • Periksa apakah akun tersebut memiliki akses Buat tag dan Baca .
      • Tidak:
        • Apakah alur Anda dalam proyek publik?
          • Ya: Anda tidak dapat mengakses sumber daya di luar proyek publik Anda. Buat proyek menjadi privat.
          • Tidak: Anda perlu mengonfigurasi izin untuk mengakses repositori lain dalam koleksi proyek yang sama.

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.

Artikel terkait

• Pemicu terjadwal
• Pemicu penyelesaian alur