Bagikan melalui

Membangun repositori GitHub Enterprise Server

  • Artikel

Azure DevOps

Anda dapat mengintegrasikan GitHub Enterprise Server lokal Anda dengan Azure Pipelines. Server lokal Anda mungkin terekspos ke Internet atau mungkin tidak.

Jika GitHub Enterprise Server Anda dapat dijangkau dari server yang menjalankan layanan Azure Pipelines, maka:

  • Anda dapat menyiapkan build klasik dan alur YAML
  • Anda dapat mengonfigurasi pemicu CI, PR, dan terjadwal

Jika GitHub Enterprise Server Anda tidak dapat dijangkau dari server yang menjalankan layanan Azure Pipelines, maka:

  • Anda hanya dapat menyiapkan alur build klasik
  • Anda hanya dapat memulai build manual atau terjadwal
  • Anda tidak dapat menyiapkan alur YAML
  • Anda tidak dapat mengonfigurasi pemicu CI atau PR untuk alur build klasik Anda

Jika server lokal Anda dapat dijangkau dari agen yang dihosting Microsoft, maka Anda dapat menggunakannya untuk menjalankan alur Anda. Jika tidak, Anda harus menyiapkan agen yang dihost sendiri yang dapat mengakses server lokal Anda dan mengambil kode.

Dapat dijangkau dari Azure Pipelines

Hal pertama yang perlu diperiksa adalah apakah GitHub Enterprise Server Anda dapat dijangkau dari layanan Azure Pipelines.

  1. Di antarmuka pengguna Azure DevOps Anda, navigasikan ke pengaturan proyek Anda, dan pilih Koneksi Layanan di bawah Alur.
  2. Pilih Koneksi layanan baru dan pilih GitHub Enterprise Server sebagai jenis koneksi.
  3. Masukkan informasi yang diperlukan untuk membuat koneksi ke GitHub Enterprise Server Anda.
  4. Pilih Verifikasi di panel koneksi layanan.

Jika verifikasi lolos, server yang menjalankan layanan Azure Pipelines dapat menjangkau GitHub Enterprise Server lokal Anda. Anda dapat melanjutkan dan menyiapkan koneksi. Kemudian, Anda dapat menggunakan koneksi layanan ini saat membuat build klasik atau alur YAML. Anda juga dapat mengonfigurasi pemicu CI dan PR untuk alur. Sebagian besar fitur di Azure Pipelines yang berfungsi dengan GitHub juga berfungsi dengan GitHub Enterprise Server. Tinjau dokumentasi gitHub untuk memahami fitur-fitur ini. Berikut adalah beberapa perbedaan:

  • Integrasi antara GitHub dan Azure Pipelines menjadi lebih mudah melalui aplikasi Azure Pipelines di marketplace GitHub. Aplikasi ini memungkinkan Anda menyiapkan integrasi tanpa harus mengandalkan token OAuth pengguna tertentu. Kami tidak memiliki aplikasi serupa yang berfungsi dengan GitHub Enterprise Server. Jadi, Anda harus menggunakan PAT, nama pengguna dan kata sandi, atau OAuth untuk menyiapkan koneksi antara Azure Pipelines dan server GitHub Enterprise.
  • Azure Pipelines mendukung sejumlah fitur keamanan GitHub untuk memvalidasi kontribusi dari fork eksternal. Misalnya, rahasia yang disimpan dalam alur tidak tersedia untuk pekerjaan yang sedang berjalan. Perlindungan ini tidak tersedia saat bekerja dengan server GitHub Enterprise.
  • Pemicu komentar tidak tersedia dengan server GitHub Enterprise. Anda tidak dapat menggunakan komentar dalam permintaan pull repositori server GitHub Enterprise untuk memicu alur.
  • Pemeriksaan GitHub tidak tersedia di server GitHub Enterprise. Semua pembaruan status melalui status dasar.

Tidak dapat dijangkau dari Azure Pipelines

Ketika verifikasi koneksi GitHub Enterprise Server seperti yang dijelaskan di bagian di atas gagal, maka Azure Pipelines tidak dapat berkomunikasi dengan server Anda. Hal ini kemungkinan disebabkan oleh bagaimana jaringan perusahaan Anda disiapkan. Misalnya, firewall di jaringan Anda dapat mencegah lalu lintas eksternal mencapai server Anda. Anda memiliki dua opsi dalam hal ini:

  • Bekerja dengan departemen TI Anda untuk membuka jalur jaringan antara Azure Pipelines dan GitHub Enterprise Server. Misalnya, Anda dapat menambahkan pengecualian ke aturan firewall Anda untuk memungkinkan lalu lintas dari Azure Pipelines mengalir. Lihat bagian di IP Azure DevOps untuk melihat alamat IP mana yang perlu Anda izinkan. Selain itu, Anda harus memiliki entri DNS publik untuk GitHub Enterprise Server sehingga Azure Pipelines dapat menyelesaikan FQDN server Anda ke alamat IP. Dengan semua perubahan ini, coba buat dan verifikasi koneksi GitHub Enterprise Server di Azure Pipelines.

  • Alih-alih menggunakan koneksi GitHub Enterprise Server, Anda dapat menggunakan koneksi Git Lainnya. Pastikan untuk menghapus centang opsi untuk Mencoba mengakses server Git ini dari Azure Pipelines. Dengan jenis koneksi ini, Anda hanya dapat mengonfigurasi alur build klasik. Pemicu CI dan PR tidak akan berfungsi dalam konfigurasi ini. Anda hanya dapat memulai eksekusi alur manual atau terjadwal.

Dapat dijangkau dari agen yang dihosting Microsoft

Keputusan lain yang mungkin harus Anda buat adalah apakah akan menggunakan agen yang dihosting Microsoft atau agen yang dihost sendiri untuk menjalankan alur Anda. Ini sering muncul apakah agen yang dihosting Microsoft dapat menjangkau server Anda. Untuk memeriksa apakah mereka bisa, buat alur sederhana untuk menggunakan agen yang dihosting Microsoft dan pastikan untuk menambahkan langkah untuk memeriksa kode sumber dari server Anda. Jika ini lolos, maka Anda dapat terus menggunakan agen yang dihosting Microsoft.

Tidak dapat dijangkau dari agen yang dihosting Microsoft

Jika alur pengujian sederhana yang disebutkan di bagian di atas gagal dengan kesalahan TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting, maka GitHub Enterprise Server tidak dapat dijangkau dari agen yang dihosting Microsoft. Ini lagi-lagi mungkin disebabkan oleh firewall yang memblokir lalu lintas dari server ini. Anda memiliki dua opsi dalam hal ini:

  • Bekerja sama dengan departemen IT Anda untuk membuka jalur jaringan antara agen yang dihosting Microsoft dan GitHub Enterprise Server. Lihat bagian tentang jaringan di agen yang dihosting Microsoft.

  • Beralih menggunakan agen yang dihost sendiri atau agen set skala. Agen-agen ini dapat disiapkan dalam jaringan Anda dan karenanya akan memiliki akses ke GitHub Enterprise Server. Agen ini hanya memerlukan koneksi keluar ke Azure Pipelines. Tidak perlu membuka firewall untuk koneksi masuk. Pastikan bahwa nama server yang Anda tentukan saat membuat koneksi GitHub Enterprise Server dapat diselesaikan dari agen yang dihost sendiri.

Alamat IP Azure DevOps

Azure Pipelines mengirim permintaan ke GitHub Enterprise Server ke:

  • Kueri untuk daftar repositori selama pembuatan alur (alur klasik dan YAML)
  • Cari file YAML yang ada selama pembuatan alur (alur YAML)
  • File YAML check-in (alur YAML)
  • Mendaftarkan webhook selama pembuatan alur (alur klasik dan YAML)
  • Menyajikan editor untuk file YAML (alur YAML)
  • Mengatasi templat dan memperluas file YAML sebelum eksekusi (alur YAML)
  • Periksa apakah ada perubahan sejak eksekusi terjadwal terakhir (alur klasik dan YAML)
  • Ambil detail tentang penerapan dan tampilan terbaru yang ada di antarmuka pengguna (alur klasik dan YAML)

Anda dapat mengamati bahwa alur YAML pada dasarnya memerlukan komunikasi antara Azure Pipelines dan GitHub Enterprise Server. Oleh karena itu, tidak mungkin untuk menyiapkan alur YAML jika GitHub Enterprise Server tidak terlihat oleh Azure Pipelines.

Saat Anda menggunakan koneksi Git Lain untuk menyiapkan alur klasik, nonaktifkan komunikasi antara layanan Azure Pipelines dan GitHub Enterprise Server, dan gunakan agen yang dihost sendiri untuk membangun kode, Anda akan mendapatkan pengalaman yang terdegradasi:

  • Anda harus mengetikkan nama repositori secara manual selama pembuatan alur
  • Anda tidak dapat menggunakan pemicu CI atau PR karena Azure Pipelines tidak dapat mendaftarkan webhook di GitHub Enterprise Server
  • Anda tidak dapat menggunakan pemicu terjadwal dengan opsi untuk membuat hanya ketika ada perubahan
  • Anda tidak dapat melihat informasi tentang penerapan terbaru di antarmuka pengguna

Jika Anda ingin menyiapkan alur YAML atau jika Anda ingin meningkatkan pengalaman dengan alur klasik, penting bagi Anda untuk mengaktifkan komunikasi dari Azure Pipelines ke GitHub Enterprise Server.

Untuk mengizinkan lalu lintas dari Azure DevOps mencapai GitHub Enterprise Server Anda, tambahkan alamat IP atau tag layanan yang ditentukan dalam Koneksi masuk ke daftar izin firewall Anda. Jika Anda menggunakan ExpressRoute, pastikan juga menyertakan rentang IP ExpressRoute ke daftar izin firewall Anda.

Batasan

  • 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 di jendela Pilih cabang untuk cabang Default untuk pengaturan build manual dan terjadwal, atau saat memilih cabang saat menjalankan alur secara manual.

    Jika Anda tidak melihat cabang yang Diinginkan dalam daftar, ketik nama cabang yang diinginkan secara manual di cabang Default untuk bidang build manual dan terjadwal.

    Jika Anda mengklik elipsis dan membuka dialog Pilih cabang dan menutupnya tanpa memilih cabang yang valid dari daftar drop-down, Anda mungkin melihat Beberapa pengaturan memerlukan pesan perhatian dan Pengaturan ini diperlukan pesan di bawah Cabang Default untuk build manual dan terjadwal. Untuk mengatasi pesan ini, buka kembali alur dan masukkan nama langsung di cabang Default untuk bidang build manual dan terjadwal.

FAQ

Masalah yang terkait dengan integrasi GitHub Enterprise termasuk dalam kategori berikut:

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

    Antarmuka pengguna pengaturan alur.

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

    Ambil alih pemicu YAML dari sini.

  • Webhook digunakan untuk mengomunikasikan pembaruan dari GitHub Enterprise ke Azure Pipelines. Di GitHub Enterprise, navigasikan ke pengaturan untuk repositori Anda, lalu ke Webhooks. Verifikasi bahwa webhook ada. Biasanya Anda akan melihat dua webhook - dorong, pull_request. Jika tidak, maka Anda harus membuat ulang koneksi layanan dan memperbarui alur untuk menggunakan koneksi layanan baru.

  • Pilih masing-masing webhook di GitHub Enterprise 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.

  • Saat Azure Pipelines menerima pemberitahuan dari GitHub, Azure Pipelines mencoba menghubungi GitHub dan mengambil informasi selengkapnya tentang file repositori dan YAML. Jika GitHub Enterprise Server berada di belakang firewall, lalu lintas ini mungkin tidak mencapai server Anda. Lihat Alamat IP Azure DevOps dan verifikasi bahwa Anda telah memberikan pengecualian untuk semua alamat IP yang diperlukan. Alamat IP ini mungkin telah berubah karena Anda awalnya telah menyiapkan aturan pengecualian.

  • 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.
    • Instans GitHub Enterprise Server Anda mungkin kurang provisi, memperlambat permintaan pemrosesan dari Azure Pipelines. Baca selengkapnya tentang pertimbangan perangkat keras untuk GitHub Enterprise Server.

Gagal checkout

Apakah Anda menggunakan agen yang dihosting Microsoft? Jika demikian, agen ini mungkin tidak dapat menjangkau GitHub Enterprise Server Anda. Lihat Tidak dapat dijangkau dari agen yang dihosting Microsoft untuk informasi selengkapnya.

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.