Blog

Cara Mengatur Tes API Otomatis Setiap Malam di GitHub Actions, GitLab & Jenkins

Siapkan build malam untuk API Anda: jadwalkan tes regresi otomatis di CI dengan Apidog CLI. Salin-tempel konfigurasi cron GitHub Actions, GitLab, dan Jenkins untuk mendeteksi kegagalan pada pagi hari.

Ashley Innocent

Ashley Innocent

15 June 2026

Cara Mengatur Tes API Otomatis Setiap Malam di GitHub Actions, GitLab & Jenkins

Apidog untuk Perusahaan

Penerapan On-Premises

SSO & RBAC

Sesuai SOC 2

Jelajahi Apidog Enterprise

Tes API Anda berhasil pada setiap permintaan penarikan (pull request). Build berwarna hijau. Anda merilisnya. Kemudian pukul 9 pagi seseorang di zona waktu lain melaporkan bahwa proses checkout mengembalikan 500, dan tidak ada yang mengubah kode checkout. Yang berubah adalah sandbox pembayaran pihak ketiga, migrasi database yang berjalan semalam, atau token yang diam-diam kedaluwarsa. Tes per-commit Anda tidak pernah menangkapnya karena tidak ada yang bergerak di repositori Anda.

Ini adalah celah yang ditutup oleh nightly build. Nightly build adalah proses uji penuh terjadwal yang dijalankan sekali sehari, biasanya pada dini hari, terhadap layanan dan lingkungan nyata Anda, bukan hanya pada perubahan kode. Ini menangkap kegagalan yang terjadi di antara commit: penyimpangan data, integrasi yang tidak stabil, kredensial yang kedaluwarsa, kebocoran kinerja yang lambat, dan pelanggaran kontrak yang diperkenalkan oleh layanan yang tidak Anda kendalikan. Khusus untuk API, nightly regression run adalah sistem peringatan dini termurah yang dapat Anda siapkan.

Panduan ini akan memandu Anda membangun sistem itu secara menyeluruh dengan Apidog. Anda akan merancang rangkaian regresi, menghasilkan eksekusi baris perintah dengan Apidog CLI, menyambungkannya ke tugas CI terjadwal di GitHub Actions, GitLab, dan Jenkins, dan mendapatkan laporan yang menunggu Anda sebelum standup. Jika Anda pernah men-debug pemadaman yang seharusnya sudah ditandai oleh nightly run berjam-jam sebelumnya, ini adalah alur kerja yang mengembalikan jam-jam tersebut.

tombol

Mengapa tes per-commit tidak cukup

Integrasi berkelanjutan melatih kita untuk menguji setiap push. Itu bagus, dan Anda harus terus melakukannya. Tetapi tes per-commit menjawab pertanyaan yang sempit: "apakah perubahan ini merusak sesuatu?" Mereka berjalan cepat, sering, dan lingkupnya dijaga agar pengembang tidak terhambat. Pembatasan lingkup itulah mengapa mereka melewatkan seluruh kelas masalah.

Nightly build menjawab pertanyaan yang lebih luas: "apakah sistem masih sehat saat ini, terlepas dari apakah ada yang menyentuhnya?" Perbedaan ini penting karena produksi memiliki bagian yang bergerak yang tidak pernah dilihat oleh commit Anda.

Jadi polanya adalah dua tingkat, bukan salah satu dari keduanya. Tes smoke cepat menjaga setiap commit. Suite regresi yang lebih dalam berjalan sesuai jadwal. Tingkat nightly adalah tempat Anda menempatkan semua yang terlalu lambat, terlalu luas, atau terlalu bergantung pada dunia nyata untuk berada dalam loop internal.

Apa saja yang termasuk dalam rangkaian regresi API nightly

Sebelum Anda menjadwalkan apa pun, putuskan apa yang sebenarnya diperiksa oleh nightly run. Suite nightly lebih luas daripada tes smoke commit-gate Anda dan lebih menyeluruh daripada ping kesehatan cepat. Targetkan cakupan yang akan membuat Anda malu jika gagal secara diam-diam.

Suite API nightly yang solid mencakup:

Jika Anda belum pernah menulis kasus terstruktur seperti ini, templat dan contoh kasus uji API adalah titik awal yang baik, dan penegasan API mencakup cara memvalidasi isi respons, status, header, dan waktu secara tepat.

Langkah 1: Bangun rangkaian regresi di Apidog

Apidog memperlakukan pengujian sebagai bagian kelas satu dari siklus hidup API, bukan sebagai tambahan. Anda merancang endpoint, lalu merangkainya ke dalam skenario pengujian yang mencerminkan alur kerja nyata. Skenario adalah daftar langkah-langap terurut di mana setiap langkah adalah permintaan API dengan penegasan, dan di mana data mengalir dari satu langkah ke langkah berikutnya.

Berikut adalah bentuk skenario regresi checkout:

  1. POST /auth/login: kirim kredensial, asert 200, ekstrak accessToken dari respons ke dalam variabel.
  2. POST /carts: buat keranjang menggunakan token, asert 201, ekstrak cartId.
  3. POST /carts/{cartId}/items: tambahkan produk, asert 200, asert total dari isi respons sama dengan harga yang diharapkan.
  4. POST /checkout: kirim keranjang, asert 200, asert order.status adalah "confirmed".
  5. GET /orders/{orderId}: baca kembali pesanan, asert bahwa pesanan tersebut disimpan dengan item baris yang benar.

Di Apidog, Anda membangun ini secara visual. Setiap langkah mendapatkan penegasan tanpa menulis boilerplate: penegasan visual seperti "status respons adalah 200" atau "JSONPath $.order.status sama dengan confirmed." Untuk kesesuaian skema, Apidog dapat memvalidasi respons terhadap definisi OpenAPI yang disimpan secara otomatis, sehingga Anda tidak perlu menulis pemeriksaan untuk setiap bidang secara manual.

Beberapa aturan desain menjaga agar suite nightly tetap terpelihara:

Jika Anda berasal dari alat lain, ini memetakan dengan jelas ke konsep yang Anda ketahui. Gambaran yang lebih luas tentang merangkai skenario hidup di panduan orkestrasi pengujian API, dan jika Anda belum pernah menjalankan pengujian terstruktur di Apidog sebelumnya, cara menguji API dengan Apidog adalah titik awal langkah demi langkah. Unduh Apidog dan bangun satu skenario sebelum Anda membaca lebih lanjut; sisa panduan ini mengasumsikan Anda memiliki suite untuk dijalankan.

Langkah 2: Jalankan suite dari baris perintah

Nightly build berjalan tanpa pengawasan, sehingga membutuhkan runner tanpa kepala (headless runner). Itu adalah Apidog CLI, paket npm yang menjalankan skenario pengujian Anda yang disimpan dari terminal mana pun, tanpa memerlukan GUI. Ini dibangun untuk hal ini: menjalankan otomatis di dalam pipeline CI/CD.

Instal secara global. CLI membutuhkan Node.js v16 atau yang lebih baru.

npm install -g apidog-cli

Untuk menjalankan skenario online (yang ada di proyek Apidog Anda), Anda memerlukan dua hal: token akses dan ID skenario atau suite. Hasilkan token di Apidog di bawah pengaturan CI/CD, di mana ada tombol "Tambah token akses". Perlakukan token itu seperti kata sandi; ia masuk ke dalam rahasia, tidak pernah di repositori Anda.

Perintah untuk menjalankan satu skenario pengujian terlihat seperti ini:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 123456 \
  -e 789 \
  -r cli,html \
  --out-dir ./apidog-reports

Flag demi flag, menggunakan opsi Apidog CLI yang sebenarnya:

Flag lain mendapatkan tempatnya dalam nightly run. -n, --iteration-count <n> mengulang eksekusi untuk menampilkan ketidakstabilan. -d, --iteration-data <path> memasukkan file CSV atau JSON sehingga satu skenario berjalan di banyak baris data; sempurna untuk pengujian batas. --env-var "key=value" dan --global-var "key=value" menyuntikkan nilai pada waktu berjalan, itulah cara Anda menjaga kredensial keluar dari skenario yang disimpan.

Anda tidak perlu menghafal ini. Apidog menghasilkan perintah yang tepat untuk Anda: buka panel CI/CD di klien, pilih skenario atau suite Anda, dan salin baris apidog run yang sudah jadi langsung ke konfigurasi pipeline Anda. Jalankan sekali secara lokal terlebih dahulu untuk mengonfirmasi bahwa itu hijau sebelum Anda menjadwalkannya.

Langkah 3: Jadwalkan sebagai nightly build

Nightly build adalah perintah ini pada pengatur waktu. Setiap platform CI mendukung pekerjaan terjadwal melalui sintaks cron. Polanya identik di semua platform: pemicu harian, token akses dari rahasia, eksekusi CLI, dan laporan diarsipkan sebagai artefak.

GitHub Actions

GitHub Actions mendukung pemicu schedule dengan cron standar. Alur kerja ini berjalan pada pukul 02:00 UTC setiap hari dan juga menampilkan tombol manual melalui workflow_dispatch.

name: Nightly API Regression

on:
  schedule:
    - cron: '0 2 * * *'   # 02:00 UTC daily
  workflow_dispatch:        # allow manual runs

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run nightly regression suite
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            --test-suite ${{ vars.APIDOG_SUITE_ID }} \
            -e ${{ vars.APIDOG_ENV_ID }} \
            -r cli,html \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-nightly-report
          path: ./apidog-reports

if: always() pada langkah pengunggahan itu penting: Anda ingin laporan diarsipkan bahkan ketika eksekusi gagal, karena kegagalan adalah saat Anda benar-benar perlu membacanya. Perhatikan bahwa pekerjaan terjadwal GitHub berjalan dalam UTC dan dapat tertunda selama beban puncak, jadi jangan jadwalkan apa pun yang perlu dipicu pada detik yang tepat.

GitLab CI/CD

GitLab menjadwalkan pipeline melalui UI (CI/CD > Schedules) daripada di YAML, kemudian pekerjaan Anda mengacu pada kondisi aturan sehingga hanya berjalan sesuai jadwal, bukan pada setiap push.

nightly-regression:
  image: node:20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  before_script:
    - npm install -g apidog-cli
  script:
    - apidog run
        --access-token "$APIDOG_ACCESS_TOKEN"
        --test-suite "$APIDOG_SUITE_ID"
        -e "$APIDOG_ENV_ID"
        -r cli,html
        --out-dir ./apidog-reports
  artifacts:
    when: always
    paths:
      - apidog-reports/
    expire_in: 30 days

Tetapkan APIDOG_ACCESS_TOKEN sebagai variabel CI/CD yang disembunyikan dan dilindungi, lalu buat jadwal pipeline dengan ekspresi cron seperti 0 2 * * *. Blok rules menjaga pekerjaan ini agar tidak berjalan pada commit biasa.

Jenkins

Di Jenkins, pipeline dengan pemicu cron melakukan pekerjaan yang sama. Simpan token sebagai kredensial dan tarik dengan withCredentials.

pipeline {
    agent any
    triggers {
        cron('H 2 * * *')   // sekitar 02:00, H menyebarkan beban
    }
    stages {
        stage('Install CLI') {
            steps { sh 'npm install -g apidog-cli' }
        }
        stage('Nightly regression') {
            steps {
                withCredentials([string(credentialsId: 'apidog-token',
                                        variable: 'APIDOG_ACCESS_TOKEN')]) {
                    sh '''
                        apidog run \
                          --access-token $APIDOG_ACCESS_TOKEN \
                          --test-suite $APIDOG_SUITE_ID \
                          -e $APIDOG_ENV_ID \
                          -r cli,html \
                          --out-dir ./apidog-reports
                    '''
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: 'apidog-reports/**', allowEmptyArchive: true
        }
    }
}

H dalam H 2 * * * adalah kemudahan Jenkins: ia memilih menit stabil dalam satu jam sehingga semua pekerjaan nightly Anda tidak bersamaan tepat pukul 02:00.

Bidang cron itu sama di ketiga platform. 0 2 * * * berarti menit 0, jam 2, setiap hari. Ingin dua kali semalam untuk menangkap masalah lebih awal? 0 2,14 * * *. Hanya hari kerja? 0 2 * * 1-5. Pilih waktu ketika lingkungan staging Anda sepi dan sandbox eksternal aktif.

Langkah 4: Jadikan kegagalan tidak mungkin diabaikan

Nightly run yang gagal ke log yang tidak ada yang membacanya lebih buruk daripada tidak ada nightly run; itu membangun kepercayaan diri yang salah. Intinya adalah peringatan. Hubungkan hasilnya ke mana pun tim Anda sudah melihat.

Kode keluar CLI adalah pengait Anda. apidog run keluar bukan nol ketika sebuah skenario gagal, sehingga CI secara otomatis mengubah pekerjaan menjadi merah. Dari sana:

Satu disiplin menjaga nightly build tetap dapat dipercaya: perlakukan kegagalan sebagai bug nyata sampai terbukti sebaliknya. Cara tercepat untuk membunuh suite nightly adalah membiarkan tes yang tidak stabil melatih semua orang untuk mengabaikan yang merah. Jika sebuah skenario gagal secara sporadis, perbaiki tes atau lingkungannya; jangan mengabaikannya. Berjalan dengan -n untuk mengulang skenario, atau menstabilkan data yang bergantung pada skenario Anda, biasanya menunjukkan ketidakstabilan yang sebenarnya.

Mengapa Apidog cocok dengan pola nightly

Anda dapat merangkai pipeline API nightly dari bagian-bagian terpisah: satu alat untuk merancang, yang lain untuk menulis tes, yang ketiga untuk menjalankannya tanpa kepala, dan validator skema yang terpasang. Banyak tim hidup seperti itu, dan itu berhasil sampai bagian-bagiannya menyimpang. Gesekan muncul pada pukul 2 pagi ketika tes yang dijalankan runner tidak lagi cocok dengan API yang sebenarnya Anda rilis.

Apidog menyatukan itu menjadi satu alur kerja. Endpoint yang Anda rancang, skenario yang Anda uji, skema yang Anda validasi, dan perintah yang Anda jadwalkan semuanya mengacu pada sumber kebenaran yang sama. Ketika Anda mengubah sebuah endpoint, skenario dan pemeriksaan skema ikut bergerak. Tidak ada langkah ekspor, tidak ada koleksi yang diam-diam menjadi usang, tidak ada salinan kontrak kedua untuk disinkronkan. Jika Anda pernah merasakan sakit koleksi Postman yang bukan sumber kebenaran nyata, desain sumber tunggal itulah perbedaannya.

CLI adalah mesin yang sama dengan GUI, sehingga skenario yang Anda debug secara visual di meja Anda berjalan identik di CI pada pukul 2 pagi. Anda membangun dan memperbaiki tes dengan visibilitas penuh, lalu menjalankannya tanpa kepala dengan satu perintah. Simetri itulah yang membuat nightly build menjadi sesuatu yang Anda percaya daripada sesuatu yang Anda awasi.

Pertanyaan yang Sering Diajukan

Apa perbedaan antara nightly build dan continuous integration?

Continuous integration menjalankan tes pada setiap perubahan kode untuk menangkap regresi pada commit baru. Nightly build berjalan pada jadwal tetap, biasanya semalam, terlepas dari apakah ada perubahan. CI menangkap apa yang tim Anda rusak; nightly run menangkap apa yang dunia luar rusak: token kedaluwarsa, dependensi yang menyimpang, perubahan data, dan perayapan kinerja yang lambat. Pipeline yang matang menjalankan keduanya. Tes smoke cepat menjaga setiap commit, dan suite regresi yang lebih luas berjalan nightly.

Jam berapa seharusnya nightly build berjalan?

Pilih jendela waktu ketika lingkungan pengujian Anda tidak aktif dan layanan eksternal yang Anda andalkan dapat dijangkau. Bagi banyak tim, itu adalah pukul 1 pagi hingga 4 pagi waktu setempat. Jika API Anda memanggil sandbox pihak ketiga, konfirmasikan bahwa sandbox tersebut aktif pada jam tersebut; beberapa penyedia membatasi atau menjeda semalam. Hindari menjadwalkan tepat pada jam-jam tertentu di CI bersama, di mana ribuan pekerjaan dipicu sekaligus; menggeser beberapa menit (atau menggunakan sintaks H Jenkins) menyebarkan beban.

Dapatkah saya menjalankan suite nightly terhadap produksi?

Jalankan pemeriksaan hanya-baca terhadap produksi dengan aman. Untuk apa pun yang menulis data, arahkan suite nightly ke lingkungan staging atau pra-produksi khusus dengan data realistis, atau gunakan operasi idempoten dan langkah pembersihan. Pola umum adalah eksekusi regresi baca-tulis penuh terhadap staging ditambah eksekusi smoke hanya-baca kecil terhadap produksi untuk mengonfirmasi bahwa sistem langsung dapat dijangkau dan merespons dengan benar.

Bagaimana ini berbeda dari pemantauan?

Pemantauan uptime menjawab "apakah API aktif?" Suite regresi nightly menjawab "apakah API benar?" Pemantauan melakukan ping ke endpoint dan memeriksa 200. Nightly run menjalankan alur kerja penuh, memvalidasi isi respons terhadap skema Anda, memeriksa batas otentikasi, dan menegaskan aturan bisnis. Keduanya saling melengkapi; pemantauan berkelanjutan dan dangkal, pengujian nightly periodik dan mendalam.

Apakah saya perlu menulis kode untuk menjadwalkan tes API?

Tidak. Anda membangun skenario secara visual di Apidog tanpa skrip, lalu menyalin perintah apidog run yang dihasilkan dari panel CI/CD. Satu-satunya "kode" adalah beberapa baris YAML atau konfigurasi pipeline yang memberi tahu platform CI Anda kapan harus dijalankan, dan itu adalah template di atas. Jika Anda ingin melihat bagaimana runner baris perintah secara umum dibandingkan, Postman CLI vs Newman dan menjalankan koleksi di CI tanpa Newman mencakup alternatifnya.

Siapkan Nightly Run Pertama Anda

Mulai dari yang kecil. Pilih satu alur kerja penting, alur login Anda atau jalur checkout Anda, dan bangun sebagai satu skenario Apidog dengan penegasan nyata. Jalankan secara lokal dengan CLI sampai hijau. Masukkan perintah yang dihasilkan ke dalam pekerjaan terjadwal menggunakan salah satu template di atas. Hubungkan kegagalan ke obrolan tim Anda. Itu adalah nightly build yang berfungsi dalam satu sore.

Dari sana, kembangkan suite. Tambahkan skenario untuk perjalanan yang paling penting berikutnya, aktifkan validasi skema di seluruh papan, dan atur anggaran kinerja pada endpoint panas Anda. Dalam seminggu Anda akan memiliki jaring regresi yang menangkap kegagalan yang tidak pernah dirancang untuk dilihat oleh tes per-commit Anda, dan Anda akan mendengarnya dari pesan obrolan pada pukul 2 pagi daripada dari pelanggan pada pukul 9.

tombol

Mengembangkan API dengan Apidog

Apidog adalah alat pengembangan API yang membantu Anda mengembangkan API dengan lebih mudah dan efisien.

Daftar gratisUnduh