Mengelola dan men-debug alur kerja di GitHub Actions

10 menit

Ingat bahwa tujuan Anda adalah mengotomatiskan proses pembuatan dan penerbitan kode sehingga fitur diperbarui setiap kali pengembang menambahkan perubahan ke basis kode.

Untuk menerapkan proses ini, Anda mempelajari cara:

Identifikasi peristiwa yang memicu alur kerja.
Gunakan log alur kerja GitHub Actions.
Simpan dan akses artefak pembangunan.
Mengotomatiskan penambahan label ke permintaan pull setelah peninjauan.

Mengidentifikasi peristiwa yang memicu alur kerja

Memahami apa yang memicu alur kerja GitHub Actions sangat penting untuk penelusuran kesalahan, audit, dan peningkatan alur CI/CD. Jenis pemicu termasuk pendorongan ke cabang, permintaan pull yang dibuat atau diperbarui, pekerjaan terjadwal, atau pengiriman manual. Anda dapat mengidentifikasi peristiwa pemicu dengan memeriksa eksekusi alur kerja, perubahan repositori, dan masalah GitHub terkait atau permintaan pull.

Diagram yang memperlihatkan berbagai pemicu alur kerja di GitHub Actions, seperti push, pull request, schedule, dan manual dispatch.

Apa itu pemicu alur kerja?

Pemicu alur kerja adalah peristiwa yang menyebabkan alur kerja berjalan. GitHub mendukung berbagai jenis pemicu, termasuk:

push atau pull_request (berdasarkan perubahan kode)
workflow_dispatch (pemicu manual)
schedule (Pekerjaan cron)
repository_dispatch (sistem eksternal)
Masalah, diskusi, dan peristiwa permintaan pull (misalnya, issues.opened, pull_request.closed)

Mengidentifikasi peristiwa pemicu

Anda dapat mengidentifikasi peristiwa pemicu alur kerja dengan beberapa cara:

Gunakan UI GitHub Actions:
1. Di repositori Anda, pilih tab Tindakan .
2. Pilih proses alur kerja.
Jenis peristiwa, seperti push, , pull_requestatau workflow_dispatch, muncul di bagian atas ringkasan eksekusi alur kerja.
Gunakan github.event_name dalam log atau dalam alur kerja.
- GitHub memaparkan data konteks selama alur kerja berjalan. Variabel github.event_name memberi tahu Anda peristiwa mana yang memicu alur kerja.
- Anda dapat mencetak informasi sebagai langkah untuk penelusuran kesalahan:
```
-name: Show event trigger
  run: echo "Triggered by ${{ github.event_name }}"
```
Gunakan detail eksekusi alur kerja:
- Jika Anda memeriksa alur kerja yang berjalan secara terprogram, seperti dengan menggunakan API, objek eksekusi menyertakan properti event yang menentukan pemicu alur kerja.
- Anda dapat menemukan komit Algoritma Hash Aman (SHA), aktor, dan tanda waktu untuk melacak penyebab pemicu.

Menarik kesimpulan pemicu dari dampak repositori

Anda mungkin tidak memiliki akses langsung ke eksekusi alur kerja, tetapi Anda masih ingin menyimpulkan apa yang memicu alur kerja berjalan berdasarkan aktivitas repositori:

Perilaku yang diamati	Peristiwa pemicu
Komit baru dikirim ke `main` dan alur kerja dijalankan.	peristiwa `push`
Permintaan penarikan dibuka atau diperbarui.	peristiwa `pull_request`
Kontributor menjalankan alur kerja secara manual.	`workflow_dispatch`
Alur kerja berjalan setiap hari pada waktu tertentu.	`schedule` (cron - sebuah penjadwal tugas otomatis)
Proses kerja dijalankan setelah panggilan layanan eksternal.	`repository_dispatch`
Proses berjalan saat label atau komentar ditambahkan ke sebuah isu.	peristiwa `issues.*`

Dengan meninjau tanda waktu, aktivitas pull request, dan riwayat komit, Anda sering dapat menentukan tindakan apa yang menyebabkan alur kerja dijalankan.

Untuk meringkas cara mengidentifikasi apa yang memicu alur kerja:

Periksa ringkasan eksekusi alur kerja pada tab Tindakan .
Cetak atau log github.event_name di dalam alur kerja untuk visibilitas.
Bandingkan tanda waktu dan aktivitas repositori (komit, permintaan tarik, masalah) untuk mengidentifikasi penyebab.
Gunakan konteks lengkap event untuk penyelidikan yang lebih mendalam.

Praktik ini membantu Anda men-debug, mengaudit, dan meningkatkan keandalan alur kerja di seluruh alur pengembangan dan penyebaran Anda.

Memahami efek alur kerja dengan membaca file konfigurasinya

Untuk memahami efek alur kerja dari membaca file konfigurasinya, analisis struktur dan konten file yang .yml disimpan di .github/workflows/.

File konfigurasi alur kerja menentukan informasi berikut tentang alur kerja:

Ketika berfungsi (di bagian on ).
Apa fungsinya (dalam jobs dan steps).
Tempat dilaksanakannya (bagian runs-on).
Mengapa berjalan (tujuannya, seperti pengujian, penyebaran, atau linting).
Bagaimana perilakunya dalam kondisi tertentu (lingkungan, filter, logika).

Menginterpretasikan efek alur kerja

Identifikasi pemicunya.

Untuk mengidentifikasi tindakan apa yang memulai alur kerja, lihat bagian on alur kerja.

Contohnya:
```
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:
```
Contoh alur kerja ini:
- Berjalan secara otomatis ketika kode didorong ke cabang utama (push).
- Berjalan saat permintaan pull dibuat atau diperbarui (pull_request).
- Dapat dipicu secara manual oleh pengguna (workflow_dispatch).
Identifikasi pekerjaan dan langkah-langkah alur kerja.

Untuk menentukan apa yang dilakukan alur kerja, lihat bagian jobs dan steps alur kerja.

Contohnya:
```
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
```
Contoh alur kerja ini:
- Menggunakan lingkungan virtual Linux (runs-on).
- Memeriksa kode repositori (steps>name).
- Menginstal dependensi proyek (steps>name).
- Menjalankan pengujian otomatis (steps>name).
Evaluasi tujuan dan hasil alur kerja.

Dengan membaca file konfigurasi, Anda dapat menjelaskan hasil alur kerja yang dimaksudkan:

"Alur kerja ini adalah alur integrasi berkelanjutan (CI). Ini memastikan bahwa kode baru yang didorong ke repositori atau dikirimkan melalui permintaan pull secara otomatis diuji. Jika pengujian gagal, UI alur kerja GitHub menampilkan hasil ini untuk membantu Anda mempertahankan kualitas kode."
Identifikasi atau atur fitur opsional yang memengaruhi cara alur kerja berjalan:
- env mengatur variabel lingkungan.
- if menambahkan logika kondisional untuk menjalankan langkah-langkah tertentu hanya saat kriteria terpenuhi.
- timeout-minutes atau continue-on-error atur eksekusi alur kerja dan penanganan kesalahan.

Mengatasi proses alur kerja yang gagal

Di repositori Anda, buka tab Tindakan .
Temukan eksekusi yang gagal (biasanya ditunjukkan oleh X merah).
Pilih alur kerja yang gagal untuk membuka ringkasan jalur proses.
Di log alur kerja, tinjau kesalahan.
1. Dalam ringkasan jalannya, perluas setiap pekerjaan dan langkah hingga Anda menemukan langkah yang menunjukkan kegagalan.
2. Pilih pekerjaan atau langkah untuk melihat lognya.
3. Cari:
  - Pesan kesalahan
  - Jejak tumpukan
  - Kode keluaran
Misalnya, pengujian yang gagal mungkin menunjukkan npm ERR! Test failed atau exit code 1.
Periksa file konfigurasi alur kerja.

Gunakan file .yml untuk menentukan:
- Apa yang coba dilakukan setiap langkah?
- Jika ada variabel lingkungan (env) atau kondisi (if) yang memengaruhi eksekusi.
- Jika kegagalan disebabkan oleh dependensi yang hilang, kesalahan sintaksis, atau langkah yang salah dikonfigurasi.
Jika langkah gagal, periksa penyebab berikut:
- Apakah dependensi berhasil diinstal pada langkah sebelumnya?
- Apakah file pengujian ada dan lulus secara lokal?

Skenario kegagalan umum

Tabel berikut ini menjelaskan skenario kegagalan alur kerja umum:

Gejala	Kemungkinan penyebabnya
Proses gagal dan menghasilkan `command not found`l	Dependensi hilang atau pengaturan yang salah
`npm install` gagal.	File rusak `package-lock.json` atau masalah jaringan
Langkah pengujian failsl	Masalah pengujian unit, file konfigurasi yang hilang, atau sintaks pengujian yang tidak valid
`Permission denied` muncul.	Izin file yang salah atau rahasia yang hilang

Mengidentifikasi cara mengakses log alur kerja di GitHub

Di repositori Anda, buka tab Tindakan .
Dalam daftar alur kerja, pilih alur kerja yang relevan.

Misalnya, jika file Anda .yml memiliki kode berikut, tautan berjudul Alur Kerja CI muncul dalam daftar:
```
name: CI Workflow
```
Pilih putaran tertentu.

Dalam daftar proses yang menunjukkan status, pilih cap waktu atau pesan commit dari proses tertentu yang hendak Anda periksa.
Perluas setiap pekerjaan dan langkah.

Halaman ringkasan eksekusi menampilkan pekerjaan seperti yang ditentukan dalam file alur kerja, seperti build atau pengujian:
1. Pilih pekerjaan untuk memperluasnya.
2. Dalam tugas, perluas langkah-langkah individu, seperti "Instal dependensi" atau "Jalankan pengujian."
Lihat output log.

Untuk melihat output log lengkap, termasuk log konsol, pesan kesalahan, dan informasi debug, pilih langkah alur kerja. Anda dapat menyalin, mencari, dan mengunduh log.

Tabel berikut ini meringkas langkah-langkah yang Anda ambil untuk mengakses log alur kerja:

Tindakan	Tujuan
Tab Tindakan	Lihat semua pelaksanaan alur kerja.
Pilih nama alur kerja	Filter berjalan menurut alur kerja.
Pilih eksekusi	Lihat hasil pekerjaan dan langkah tertentu.
Perluas langkah	Lihat log terperinci.
Mengunduh log	Unduh log untuk pemecahan masalah offline atau tim.

Catatan aksi untuk build

Saat alur kerja berjalan, alur kerja menghasilkan log yang menyertakan detail apa yang terjadi dan kesalahan atau kegagalan pengujian apa pun.

Jika terjadi kesalahan atau jika pengujian gagal, X merah alih-alih tanda centang hijau muncul di log. Anda dapat memeriksa detail kesalahan atau kegagalan untuk menyelidiki apa yang terjadi.

Cuplikan layar log GitHub Actions dengan detail pada pengujian yang gagal.

Bekerja dengan artefak

Ketika alur kerja menghasilkan sesuatu selain entri log, produk disebut artefak . Misalnya, build Node.js menghasilkan kontainer Docker yang dapat disebarkan. Kontainer adalah artefak yang dapat Anda unggah ke penyimpanan dengan menggunakan tindakan/tindakan upload-artefak . Anda nantinya dapat mengunduh artefak dari penyimpanan dengan menggunakan tindakan/unduh-artefak.

Menyimpan artefak memungkinkannya dipertahankan selama berbagai tugas. Setiap pekerjaan menggunakan instans baru VM, sehingga Anda tidak dapat menggunakan kembali artefak dengan menyimpannya di VM. Jika Anda memerlukan artefak dalam pekerjaan yang berbeda, Anda dapat mengunggah artefak ke penyimpanan dalam satu pekerjaan, dan mengunduhnya untuk pekerjaan lain.

Penyimpanan artefak

Artefak disimpan di ruang penyimpanan di GitHub. Ruang ini gratis untuk repositori publik, dan beberapa penyimpanan gratis untuk repositori privat, tergantung pada akun. GitHub menyimpan artefak Anda selama 90 hari.

Dalam cuplikan alur kerja berikut, perhatikan bahwa dalam tindakan actions/upload-artifact@main ada atribut path. Nilai atribut ini adalah jalur untuk menyimpan artefak. Dalam contoh ini, Anda menentukan publik/ untuk mengunggah semuanya ke direktori. Jika Anda hanya ingin mengunggah satu file, gunakan sesuatu seperti publik/mytext.txt.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

Untuk mengunduh artefak untuk pengujian, build harus berhasil diselesaikan dan mengunggah artefak. Dalam kode berikut, Anda menentukan bahwa pekerjaan pengujian bergantung pada pekerjaan build.

test:
    needs: build
    runs-on: ubuntu-latest

Dalam cuplikan alur kerja berikut, Anda mengunduh artefak. Sekarang pekerjaan pengujian dapat menggunakan artefak untuk pengujian.

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

Untuk informasi selengkapnya tentang menggunakan artefak dalam alur kerja, lihat Menyimpan data alur kerja sebagai artefak.

Mengotomatiskan tinjauan di GitHub dengan menggunakan alur kerja

Selain memulai alur kerja melalui peristiwa GitHub seperti push dan pull-request, Anda dapat menjalankan alur kerja sesuai jadwal atau setelah beberapa peristiwa di luar GitHub.

Anda mungkin ingin alur kerja berjalan hanya setelah pengguna menyelesaikan tindakan tertentu, seperti setelah peninjau menyetujui permintaan pull. Untuk skenario ini, Anda dapat memicu pada pull-request-review.

Tindakan lain yang dapat Anda lakukan adalah menambahkan label ke permintaan pull. Dalam hal ini, gunakan aksi pullreminders/label-when-approved-action.

Contohnya:

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

Di blok env, Anda menetapkan variabel lingkungan untuk tindakan tersebut. Misalnya, Anda dapat mengatur jumlah pemberi persetujuan yang diperlukan untuk menjalankan alur kerja. Pada contoh ini, jumlahnya satu. Variabel autentikasi secrets.GITHUB_TOKEN diperlukan karena tindakan harus membuat perubahan pada repositori Anda dengan menambahkan label. Terakhir, Anda memasukkan nama label yang akan ditambahkan.

Menambahkan label mungkin merupakan peristiwa yang memulai alur kerja lain, seperti penggabungan. Kami membahas peristiwa ini dalam modul berikutnya, yang menjelaskan penggunaan pengiriman berkelanjutan di GitHub Actions.

Saran dan Komentar

Apakah halaman ini membantu?