Alur kerja cache, berbagi, dan debug

8 menit

Di unit ini, Anda akan mempelajari cara mengoptimalkan performa, meneruskan data antar pekerjaan, dan memecahkan masalah alur kerja menggunakan log dan token.

Untuk menerapkan proses ini, Anda akan mempelajari cara:

Dependensi cache untuk alur kerja yang lebih cepat.
Meneruskan data artefak antar tugas.
Aktifkan pengelogan debug untuk alur kerja.
Akses log alur kerja dari UI GitHub dan REST API.
Gunakan token penginstalan untuk autentikasi Aplikasi GitHub.

Dependensi cache dengan tindakan cache

Saat Anda membangun alur kerja, Anda sering kali perlu menggunakan kembali output yang sama atau mengunduh dependensi dari satu eksekusi ke yang lain. Alih-alih mengunduh dependensi ini berulang-ulang, Anda dapat menyimpan cache untuk membuat alur kerja agar berjalan lebih cepat dan lebih efisien. Dependensi caching mengurangi waktu yang diperlukan untuk menjalankan beberapa langkah dalam alur kerja, karena job pada runner yang dihost GitHub dimulai di lingkungan virtual yang bersih setiap kali.

Untuk menyimpan dependensi untuk pekerjaan, gunakan tindakan GitHub cache . Tindakan ini mengambil cache yang diidentifikasi oleh kunci unik yang Anda sediakan. Saat tindakan menemukan cache, tindakan kemudian mengambil file cache ke jalur yang Anda konfigurasi. Untuk menggunakan cache tindakan, Anda perlu mengatur beberapa parameter tertentu:

Pengaturan	Deskripsi	Diperlukan
`Key`	Mengacu pada pengidentifikasi kunci yang dibuat saat menyimpan dan mencari cache.	Ya
`Path`	Mengacu pada jalur file pada runner ke cache atau pencarian.	Ya
`Restore-keys`	Terdiri dari kunci alternatif yang ada untuk cache jika kunci cache yang diinginkan tidak ditemukan.	Tidak.

steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

Pada contoh sebelumnya, path diatur ke ~/.npm dan key menyertakan sistem operasi runner dan hash SHA-256 dari file package-lock.json. Awalan kunci dengan ID (npm-cache dalam contoh ini) berguna saat Anda menggunakan restore-keys fallback dan memiliki beberapa cache.

Data artefak pass antar pekerjaan

Mirip dengan ide penyimpanan sementara dependensi dalam alur kerja Anda, Anda dapat meneruskan data di antara job di dalam alur kerja yang sama. Anda dapat meneruskan data dengan menggunakan tindakan upload-artifact dan download-artifact. Pekerjaan yang bergantung pada artefak pekerjaan sebelumnya harus menunggu pekerjaan sebelumnya berhasil diselesaikan sebelum dapat berjalan. Pendekatan ini berguna jika Anda memiliki serangkaian pekerjaan yang perlu dijalankan secara berurutan berdasarkan artefak yang diunggah dari pekerjaan sebelumnya. Misalnya, job_2 memerlukan job_1 dengan menggunakan sintaks needs: job_1.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

Contoh ini memiliki dua pekerjaan. job_1 menulis beberapa teks dalam file.txt file. Kemudian menggunakan actions/upload-artifact@v2 tindakan untuk mengunggah artefak ini dan menyimpan data untuk digunakan di masa mendatang dalam alur kerja. job_2 job_1 harus diselesaikan dengan menggunakan needs: job_1 sintaks. Kemudian menggunakan actions/download-artifact@v2 tindakan untuk mengunduh artefak tersebut, lalu mencetak konten file.txt.

Mengaktifkan pengelogan debug langkah dalam alur kerja

Dalam beberapa kasus, log alur kerja default tidak memberikan detail yang cukup bagi Anda untuk mendiagnosis mengapa alur kerja tertentu berjalan, pekerjaan, atau langkah gagal. Dalam skenario ini, Anda dapat mengaktifkan pengelogan debug tambahan untuk dua opsi: proses dan langkah-langkah. Aktifkan pengelogan diagnostik ini dengan mengatur dua rahasia repositori yang memerlukan admin akses ke repositori ke true.

Untuk menjalankan log diagnostik, atur ACTIONS_RUNNER_DEBUG rahasia di repositori yang berisi alur kerja ke true.
Untuk mengaktifkan pembuatan log diagnostik langkah, atur ACTIONS_STEP_DEBUG rahasia di repositori yang berisi alur kerja ke true.

Mengakses log alur kerja di GitHub

Ketika Anda berpikir tentang otomatisasi yang berhasil, Anda bertujuan untuk menghabiskan sedikit waktu melihat apa yang otomatis sehingga Anda dapat fokus pada apa yang relevan. Tetapi terkadang hal-hal tidak berjalan seperti yang direncanakan, dan Anda perlu meninjau apa yang terjadi. Proses debugging tersebut dapat membuat frustrasi.

GitHub memiliki tata letak terstruktur yang jelas untuk membantu Anda berpindah antar pekerjaan dengan cepat sambil mempertahankan konteks langkah penelusuran kesalahan saat ini.

Untuk melihat log alur kerja yang dijalankan di GitHub:

Di repositori Anda, buka tab Tindakan .
Di panel kiri, pilih alur kerja.
Dalam daftar pengoperasian alur kerja, pilih pengoperasian.
Di bawah Pekerjaan, pilih pekerjaan.
Baca output log.

Jika Anda memiliki beberapa eksekusi di dalam alur kerja, Anda dapat memilih filter Status setelah Anda memilih alur kerja dan mengaturnya ke Kegagalan untuk hanya menampilkan eksekusi yang gagal dalam alur kerja tersebut.

Mengakses log alur kerja dari REST API

Selain melihat log melalui GitHub, Anda dapat menggunakan GITHub REST API untuk melihat log untuk eksekusi alur kerja, menjalankan ulang alur kerja, atau bahkan membatalkan eksekusi alur kerja. Untuk melihat log eksekusi alur kerja dengan menggunakan API, kirim GET permintaan ke titik akhir log. Perlu diingat bahwa siapa pun dengan akses baca ke repositori dapat menggunakan titik akhir ini. Jika repositori bersifat privat, Anda harus menggunakan token akses dengan cakupan repo.

Misalnya, GET permintaan untuk melihat log eksekusi alur kerja tertentu mengikuti jalur ini:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Mengidentifikasi kapan menggunakan token penginstalan dari aplikasi GitHub

Saat aplikasi GitHub diinstal pada akun, Anda dapat mengautentikasinya sebagai penginstalan aplikasi dengan menggunakan installation access token untuk permintaan REST dan GraphQL API. Langkah ini memungkinkan aplikasi untuk mengakses sumber daya yang dimiliki oleh penginstalan, dengan asumsi bahwa aplikasi diberikan akses dan izin repositori yang diperlukan. Permintaan REST atau GraphQL API yang dibuat oleh penginstalan aplikasi dikaitkan dengan aplikasi.

Dalam contoh berikut, Anda mengganti INSTALLATION_ACCESS_TOKEN dengan token akses penginstalan:

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

Anda juga dapat menggunakan token akses penginstalan untuk mengautentikasi akses Git berbasis HTTP. Aplikasi Anda harus memiliki Contents izin repositori. Anda kemudian dapat menggunakan token akses penginstalan sebagai kata sandi HTTP.

Anda mengganti TOKEN dalam contoh dengan token akses penginstalan:

git clone https://x-access-token:TOKEN@github.com/owner/repo.git

Saran dan Komentar

Apakah halaman ini membantu?