Opsi alur untuk repositori Git

  • Artikel

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

Saat mengedit alur yang menggunakan repositori Git—dalam proyek Azure DevOps, GitHub, GitHub Enterprise Server, Bitbucket Cloud, atau repositori Git lainnya—Anda memiliki opsi berikut.

Fitur Azure Pipelines Azure DevOps Server 2019 dan yang lebih tinggi TFS 2018
Cabang Ya Ya Ya
Bersihkan Ya Ya Ya
Memberi tag atau memberi label sumber Proyek; Hanya klasik Proyek tim Proyek tim
Status build laporan Ya Ya Ya
Lihat submodul Ya Ya Ya
Cek keluar file dari LFS Ya Ya Ya
Mengkloning repositori kedua Ya Ya Ya
Jangan sinkronkan sumber Ya Ya Ya
Pengambilan dangkal Ya Ya Ya

Catatan

Klik Pengaturan tingkat lanjut dalam tugas Dapatkan Sumber untuk melihat beberapa opsi di atas.

Cabang

Ini adalah cabang yang ingin Anda jadikan default saat Anda mengantre build ini secara manual. Jika Anda mengatur pemicu terjadwal untuk build, ini adalah cabang tempat build Anda akan mendapatkan sumber terbaru. Cabang default tidak memiliki bantalan ketika build dipicu melalui integrasi berkelanjutan (CI). Biasanya Anda akan mengatur ini agar sama dengan cabang default repositori (misalnya, "master").

Bersihkan repositori lokal pada agen

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. Saat menggunakan agen yang dihost sendiri, tergantung pada bagaimana kumpulan agen Anda dikonfigurasi, Anda mungkin mendapatkan agen baru untuk eksekusi alur berikutnya (atau tahap atau pekerjaan dalam alur yang sama), jadi tidak membersihkan bukanlah jaminan bahwa eksekusi, pekerjaan, atau tahap berikutnya akan dapat mengakses output dari eksekusi, pekerjaan, atau tahap sebelumnya.

Catatan

Saat menggunakan agen yang dihost sendiri, tergantung pada bagaimana kumpulan agen Anda dikonfigurasi, Anda mungkin mendapatkan agen baru untuk eksekusi alur berikutnya (atau tahap atau pekerjaan dalam alur yang sama), jadi tidak membersihkan bukanlah jaminan bahwa eksekusi, pekerjaan, atau tahap berikutnya akan dapat mengakses output dari eksekusi, pekerjaan, atau tahap sebelumnya. Anda dapat menggunakan artefak Build untuk berbagi output eksekusi, tahap, atau pekerjaan alur dengan eksekusi, tahap, atau pekerjaan berikutnya.

Azure Pipelines, Azure DevOps Server 2019, dan yang lebih baru

Ada beberapa opsi bersih yang berbeda yang tersedia untuk alur YAML.

  • Langkah ini checkout memiliki clean opsi. Saat diatur ke true, alur berjalan execute git clean -ffdx && git reset --hard HEAD sebelum mengambil repositori. Untuk informasi selengkapnya, lihat Checkout.
  • Pengaturan workspace untuk job memiliki beberapa opsi bersih (output, sumber daya, semua). Untuk informasi selengkapnya, lihat Ruang Kerja.
  • Antarmuka pengguna pengaturan alur memiliki pengaturan Bersih , yang ketika diatur ke true setara dengan menentukan clean: true untuk setiap checkout langkah dalam alur Anda. Untuk mengonfigurasi pengaturan Bersih :

    1. Edit alur Anda, pilih ..., dan pilih Pemicu.

      Edit pemicu.

    2. Pilih YAML, Dapatkan sumber, dan konfigurasikan pengaturan Bersih yang Anda inginkan. Defaultnya adalah true

      Pengaturan bersih.

Untuk mengambil alih pengaturan bersih saat menjalankan alur secara manual, Anda dapat menggunakan parameter runtime. Dalam contoh berikut, parameter runtime digunakan untuk mengonfigurasi pengaturan bersih checkout.

parameters:
- name: clean
  displayName: Checkout clean
  type: boolean
  default: true
  values:
  - false
  - true

trigger:
- main

pool: FabrikamPool
#  vmImage: 'ubuntu-latest'

steps:
- checkout: self
  clean: ${{ parameters.clean }}

Secara default, clean diatur ke true tetapi dapat ditimpa saat menjalankan alur secara manual dengan menghapus centang pada kotak centang Bersih checkout yang ditambahkan untuk parameter runtime.

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.

Catatan

Anda hanya dapat menggunakan fitur ini ketika repositori sumber di build Anda adalah repositori GitHub, atau repositori Git atau TFVC dari proyek Anda.

Dalam format Label, Anda dapat menggunakan variabel yang ditentukan pengguna dan telah 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.

Melaporkan status build (Azure Pipelines, TFS 2018 dan yang lebih baru)

Anda memiliki opsi untuk memberi tim Anda tampilan status build dari repositori sumber jarak jauh Anda.

Jika sumber Anda berada di repositori Azure Repos Git di proyek Anda, maka opsi ini menampilkan lencana di halaman Kode untuk menunjukkan apakah build melewati atau gagal. Status build ditampilkan di tab berikut:

  • File: Menunjukkan status build terbaru untuk cabang yang dipilih.
  • Penerapan: Menunjukkan status build dari setiap penerapan (ini mengharuskan pemicu integrasi berkelanjutan (CI) diaktifkan untuk build Anda).
  • Cabang: Menunjukkan status build terbaru untuk setiap cabang.

Jika Anda menggunakan beberapa alur build untuk repositori yang sama dalam proyek Anda, maka Anda dapat memilih untuk mengaktifkan opsi ini untuk satu atau beberapa alur. Dalam kasus ketika opsi ini diaktifkan pada beberapa alur, lencana pada halaman Kode menunjukkan status build terbaru di semua alur. Anggota tim Anda dapat mengklik lencana status build untuk melihat status build terbaru untuk masing-masing alur build.

GitHub

Jika sumber Anda berada di GitHub, maka opsi ini menerbitkan status build Anda ke GitHub menggunakan GitHub Checks atau Status API. Jika build Anda dipicu dari permintaan pull GitHub, maka Anda dapat melihat status di halaman permintaan pull GitHub. Ini juga memungkinkan Anda untuk menetapkan kebijakan status dalam GitHub dan mengotomatiskan penggabungan. Jika build Anda dipicu oleh integrasi berkelanjutan (CI), maka Anda dapat melihat status build pada penerapan atau cabang di GitHub.

Jenis repositori jarak jauh Git lainnya

Jika sumber Anda berada di jenis repositori jarak jauh lainnya, maka Anda tidak dapat menggunakan Azure Pipelines atau TFS untuk secara otomatis menerbitkan status build ke repositori tersebut. Namun, Anda dapat menggunakan lencana build sebagai cara untuk mengintegrasikan dan menunjukkan status build dalam pengalaman kontrol versi Anda.

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

Jika Anda menggunakan beberapa checkout langkah dan memeriksa beberapa repositori, dan ingin secara eksplisit menentukan folder menggunakan path, pertimbangkan untuk menghindari jalur pengaturan yang merupakan subfolder dari jalur langkah checkout lain (yaitu C:\agent\_work\1\s\repo1 dan C:\agent\_work\1\s\repo1\repo2), jika tidak, subfolder langkah checkout akan dihapus oleh pembersihan repo lain. Harap dicatat bahwa kasus ini valid jika opsi bersih benar untuk repo1)

Catatan

Jalur checkout hanya dapat ditentukan untuk alur YAML. Untuk informasi selengkapnya, lihat Checkout dalam skema YAML.

Submodul checkout

Pilih jika Anda ingin mengunduh file dari submodul. Anda dapat memilih untuk mendapatkan submodul segera atau semua submodul yang bersarang ke kedalaman rekursi apa pun. Jika Anda ingin menggunakan LFS dengan submodul, pastikan untuk melihat catatan tentang menggunakan LFS dengan submodul.

Catatan

Untuk informasi selengkapnya tentang sintaks YAML untuk memeriksa submodul, lihat Checkout dalam skema YAML.

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, organisasi GitHub, atau akun Bitbucket Cloud seperti repositori Git yang ditentukan di atas.

    • Ditambahkan dengan menggunakan URL relatif terhadap repositori utama. Misalnya, yang satu ini akan diperiksa: git submodule add /../../submodule.git mymodule Yang ini tidak akan diperiksa: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Submodul terautentikasi

Catatan

Pastikan Anda telah mendaftarkan submodul Anda menggunakan HTTPS dan tidak menggunakan SSH.

Kredensial yang sama yang digunakan oleh agen untuk mendapatkan sumber dari repositori utama juga digunakan untuk mendapatkan sumber untuk submodul.

Jika repositori dan submodul utama Anda berada di repositori Azure Repos Git di proyek Azure DevOps Anda, maka Anda dapat memilih akun yang digunakan untuk mengakses sumber. Pada tab Opsi , pada menu lingkup otorisasi pekerjaan Build, pilih:

  • Koleksi proyek untuk menggunakan akun layanan Project Collection Build

  • Proyek saat ini untuk menggunakan akun Project Build Service.

Pastikan akun mana pun yang Anda gunakan memiliki akses ke repositori utama serta submodul.

Jika repositori dan submodul utama Anda berada di organisasi GitHub yang sama, maka token yang disimpan dalam koneksi layanan GitHub digunakan untuk mengakses sumber.

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 atau layanan Git yang sama.

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_TOKEN_DESCRIBED_ABOVE>" submodule update --init --recursive

Pastikan untuk mengganti "<BASIC_AUTH_TOKEN>" dengan 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.

Cek keluar file dari LFS

Pilih jika Anda ingin mengunduh file dari penyimpanan file besar (LFS).

Di editor klasik, pilih kotak centang untuk mengaktifkan opsi ini.

Dalam build YAML, tambahkan langkah checkout dengan lfs diatur ke true:

steps:
- checkout: self
  lfs: true

Jika Anda menggunakan TFS, atau jika Anda menggunakan Azure Pipelines dengan agen yang dihost sendiri, maka Anda harus menginstal git-lfs pada agen agar opsi ini berfungsi. Jika agen yang dihosting menggunakan Windows, pertimbangkan untuk menggunakan System.PreferGitFromPath variabel untuk memastikan bahwa alur menggunakan versi git dan git-lfs yang Anda instal di komputer. Untuk informasi selengkapnya, lihat Versi Git apa yang dijalankan agen saya?

Menggunakan Git LFS dengan submodul

Jika submodul berisi file LFS, Git LFS harus dikonfigurasi sebelum memeriksa submodul. Agen macOS dan Linux yang dihosting Microsoft telah dikonfigurasi sebelumnya dengan cara ini. Agen Windows dan agen macOS / Linux yang dihost sendiri mungkin tidak.

Sebagai solusinya, jika Anda menggunakan YAML, Anda dapat menambahkan langkah berikut sebelum checkout:

steps:
- script: |
    git config --global --add filter.lfs.required true
    git config --global --add filter.lfs.smudge "git-lfs smudge -- %%f"
    git config --global --add filter.lfs.process "git-lfs filter-process"
    git config --global --add filter.lfs.clean "git-lfs clean -- %%f"
  displayName: Configure LFS for use with submodules
- checkout: self
  lfs: true
  submodules: true
# ... rest of steps ...

Mengkloning repositori kedua

Secara default, alur Anda dikaitkan dengan satu repositori dari Azure Repos atau penyedia eksternal. Ini adalah repositori yang dapat memicu build pada penerapan dan permintaan pull.

Anda mungkin ingin menyertakan sumber dari repositori kedua dalam alur Anda. Anda dapat melakukan ini dengan menulis skrip.

git clone https://github.com/Microsoft/TypeScript.git

Jika repositori tidak publik, Anda harus meneruskan autentikasi ke perintah Git.

Azure Repos

Alur Anda akan sudah memiliki akses ke repositori lain dalam proyeknya, dan Anda dapat mengkloningnya di alur Anda menggunakan perintah skrip, seperti yang ditunjukkan dalam contoh berikut.

- script: | 
    git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" https://organization@dev.azure.com/project/FabrikamFiber/_git/reponame

Anda dapat mengkloning beberapa repositori dalam proyek yang sama dengan alur Anda dengan menggunakan cek keluar multi-repo.

Jika Anda perlu mengkloning repositori dari proyek lain yang tidak bersifat publik, Anda harus mengautentikasi sebagai pengguna yang memiliki akses ke proyek tersebut.

Catatan

Gunakan variabel rahasia untuk menyimpan kredensial dengan aman.

Variabel rahasia tidak secara otomatis tersedia untuk skrip sebagai variabel lingkungan. Lihat Variabel rahasia tentang cara memetakannya.

Untuk Azure Repos, Anda dapat menggunakan token akses pribadi dengan izin Kode (Baca). Kirim ini sebagai bidang kata sandi di header otorisasi "Dasar" tanpa nama pengguna. (Dengan kata lain, base64-encode nilai :<PAT>, termasuk titik dua.)

AUTH=$(echo -n ":$REPO_PAT" | openssl base64 | tr -d '\n')
git -c http.<repo URL>.extraheader="AUTHORIZATION: basic $AUTH" clone <repo URL> --no-checkout --branch master

Jangan sinkronkan sumber

Pekerjaan non-penyebaran secara otomatis mengambil sumber. Gunakan opsi ini jika Anda ingin melewati perilaku tersebut. 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.

Jika Anda ingin menonaktifkan pengunduhan sumber:

  • Azure Pipelines, TFS 2018, dan yang lebih baru: Klik Pengaturan tingkat lanjut, lalu pilih Jangan sinkronkan sumber.

Catatan

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

Pengambilan dangkal

Pilih jika Anda ingin membatasi seberapa jauh 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.

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 build diantrekan, 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.

Setelah Anda memilih kotak centang untuk mengaktifkan opsi ini, dalam kotak Kedalaman tentukan jumlah penerapan.

Tip

Variabel Agent.Source.Git.ShallowFetchDepth yang disebutkan di bawah ini juga berfungsi dan mengambil alih kontrol kotak centang. Dengan cara ini Anda dapat mengubah pengaturan saat Anda mengantre build.

Lebih suka Git dari jalur

Secara default, agen Windows menggunakan versi Git yang dibundel dengan perangkat lunak agen. Microsoft merekomendasikan penggunaan versi Git yang dibundel dengan agen, tetapi Anda memiliki beberapa opsi untuk mengambil alih perilaku default ini dan menggunakan versi Git yang telah diinstal mesin agen di jalur.

Untuk melihat versi Git yang digunakan oleh alur, Anda dapat melihat log untuk checkout langkah di alur Anda, seperti yang ditunjukkan dalam contoh berikut.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

Pengaturan ini selalu benar pada agen non-Windows.

Opsi Pemicu untuk Git Lainnya

Ketika repositori Git Lainnya/eksternal ditentukan, build CI mengharuskan repositori dapat diakses dari internet. Jika repositori berada di belakang firewall atau proksi, maka hanya build terjadwal dan manual yang akan berfungsi.

FAQ

Protokol apa yang dapat digunakan agen build dengan Git?

Agen mendukung HTTPS.

Agen belum mendukung SSH. Lihat Mengizinkan build untuk menggunakan autentikasi SSH saat memeriksa submodul Git.

Saya menggunakan TFS lokal dan saya tidak melihat beberapa fitur ini. Mengapa bukan?

Beberapa fitur ini hanya tersedia di Azure Pipelines dan belum tersedia secara lokal. Beberapa fitur tersedia secara lokal jika Anda telah meningkatkan ke TFS versi terbaru.