Otomatisasi Testing & Analisa Kode Laravel + React dengan GitHub Actions & SonarQube

Halo, developer kece badai! Pernah nggak sih pas lagi asyik ngoding, tiba-tiba deploy aplikasi ke server, eh malah muncul error aneh yang nggak kedeteksi pas di lokal? Atau mungkin kerja tim jadi ribet karena harus manual cek kode teman satu-satu, terus manual juga jalanin testing sebelum merge ke branch utama? Duh, primitif banget nggak sih? 😅

Tenang, di era modern ini, ada cara ciamik buat mengatasi masalah-masalah klasik itu. Namanya CI/CD! Khusus di artikel ini, kita bakal fokus ke bagian CI (Continuous Integration) pakai GitHub Actions, si asisten otomatis gratisan dari GitHub.

Apa Sih CI Itu? Kenapa Penting Banget?

Bayangin gini: Kamu dan tim lagi ngerjain satu project aplikasi web pakai Laravel 12 buat backend dan React buat frontend. Setiap kali ada anggota tim yang selesai ngoding fitur baru atau perbaikan bug dan push kodenya ke repository (tempat penyimpanan kode online, biasanya di GitHub), ada 'robot' pinter yang otomatis:

Ambil kode terbaru: Si robot langsung download kode yang baru di-push.
Install semua 'perkakas': Dia pasang semua library atau package yang dibutuhkan project (misal pakai Composer buat PHP/Laravel, dan Bun/NPM/Yarn buat React/JavaScript).
Jalanin testing otomatis: Si robot jalanin semua script tes yang udah kamu siapin buat mastiin nggak ada fitur lama yang rusak atau logika baru yang salah.
Cek kualitas kode: Dia juga bisa analisa kode kamu, cari potensi bug, celah keamanan, atau gaya penulisan kode yang kurang oke (biasanya pakai tools kayak SonarQube).
Kasih laporan: Kalau semua aman, dia kasih jempol 👍. Kalau ada masalah (misal test gagal atau kualitas kode jelek), dia bakal kasih tahu 👎 biar bisa segera diperbaiki.

Nah, proses otomatisasi dari nomor 1 sampai 5 itulah yang disebut Continuous Integration (CI). Tujuannya? Biar setiap perubahan kode bisa langsung terintegrasi dan terverifikasi secara otomatis, jadi kamu dan tim bisa:

Hemat waktu: Nggak perlu lagi testing dan cek manual berulang-ulang.
Deteksi error lebih dini: Masalah ketahuan lebih cepat, nggak nunggu numpuk di akhir.
Lebih pede rilis fitur: Kualitas kode lebih terjaga, bug minimal.
Kolaborasi tim lebih mulus: Proses review dan merge kode jadi lebih standar dan terpercaya.

Kenalan Sama GitHub Actions: Si Asisten Otomatis di GitHub

GitHub Actions ini adalah fitur bawaan GitHub yang memungkinkan kita menjalankan proses CI (dan juga CD) langsung dari repository kita. Kita tinggal buat file konfigurasi dalam format YAML (nanti kita bedah bareng), taruh di folder khusus .github/workflows/, dan voila! Si asisten GitHub Actions bakal otomatis kerja sesuai instruksi di file itu.

Enaknya lagi, GitHub Actions ini gratis untuk repository public, dan ada kuota gratis yang lumayan besar juga untuk repository private. Jadi, cocok banget buat proyek pribadi, open source, sampai kebutuhan tim skala kecil hingga menengah.

Sekilas Project Catalystack & Kebutuhan Otomatisasi

Di artikel ini, kita akan pakai contoh real dari file konfigurasi CI proyek Catalystack. Semacam starter kit atau template proyek yang udah bundling Laravel 12 (versi terbaru saat artikel ini ditulis!) dengan React, plus setup modern lainnya.

Karena tujuannya sebagai starter kit yang handal, penting banget buat Catalystack punya proses CI yang solid. Setiap ada perubahan atau kontribusi baru, harus dipastikan nggak merusak fungsi yang udah ada dan kualitas kodenya tetap terjaga. Makanya, setup GitHub Actions jadi krusial banget di sini.

Bedah Tuntas File `.github/workflows/ci.yml` (Resep Otomatisasi Kita!)

Yuk, sekarang kita kuliti satu per satu isi file ci.yml yang dipakai di Catalystack!

name: Tests

on:
  push:
    branches:
      - develop
      - main
  pull_request:
    branches:
      - develop
      - main

jobs:
  ci:
    runs-on: ubuntu-latest
    container:
      image: ramaid/image:php8.4-fullstack-cli-v2.5.0
      options: --user root
      volumes:
        - /run/docker:/run/docker

    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          # Fetch all history for all branches and tags
          fetch-depth: 0

      - name: Install Dependencies
        run: composer install --no-interaction --prefer-dist --optimize-autoloader

      - name: Setup Environment
        run: |
          cp .env.example .env
          php artisan migrate --force
          php artisan key:generate
          php artisan wayfinder:generate

      - name: Build Assets
        run: |
          bun install
          bun run build

      - name: Tests
        run: |
          XDEBUG_MODE=coverage php artisan test --coverage \
            --coverage-clover=coverage.xml \
            --log-junit=results.xml

      - name: SonarCloud Scan
        uses: SonarSource/sonarqube-scan-action@v5
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

      - name: Sonar Scan Self Hosted
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_MC_TOKEN }}
        run: |
          sonar-scanner -Dsonar.token=$SONAR_TOKEN -Dsonar.host.url=http://sonar.malescast.tech/

1. `name: Tests` - Kasih Nama Biar Nggak Bingung

Bagian pertama ini simpel banget. name: Tests cuma ngasih nama "Tests" buat keseluruhan workflow (rangkaian proses otomatis) ini. Nama ini bakal muncul di tab "Actions" di repository GitHub kamu. Fungsinya biar gampang dikenali aja, apalagi kalau nanti kamu punya banyak workflow lain (misal buat deployment, linting, dll). Kasih nama yang jelas ya!

2. `on:` - Kapan Si Asisten Mulai Kerja? (Trigger)

Nah, bagian on: ini krusial banget. Ini yang nentuin kapan si GitHub Actions harus mulai menjalankan tugas-tugasnya. Di sini, kita definisikan dua event (kejadian) utama sebagai pemicu:

push: ke branches: [develop, main]
- Artinya: Workflow "Tests" ini akan otomatis berjalan setiap kali ada dorongan (push) kode baru ke branch (cabang) develop ATAU ke branch main.
- Apa itu branch? Bayangin branch itu kayak cabang di pohon pengembangan kode kamu. Branch main (atau kadang disebut master) biasanya berisi kode stabil yang siap dirilis atau sudah dipakai di production. Branch develop sering dipakai sebagai tempat integrasi fitur-fitur baru sebelum 'naik kelas' ke main. Jadi, penting banget buat ngecek kode di kedua branch vital ini setiap ada perubahan.
pull_request: ke branches: [develop, main]
- Artinya: Workflow ini juga akan jalan setiap kali ada Pull Request (PR) yang dibuat atau di-update, yang targetnya mau digabung (merge) ke branch develop ATAU ke branch main.
- Apa itu Pull Request? PR itu mekanisme di GitHub (dan platform sejenis) dimana seorang developer 'minta izin' untuk menggabungkan kode dari branch miliknya (misal branch fitur A) ke branch lain (misal develop). Sebelum kodenya benar-benar digabung, tim bisa review dulu, diskusi, dan ya... menjalankan testing otomatis via GitHub Actions ini!
- Kenapa penting jalanin workflow saat ada PR? Ini fungsinya kayak 'penjaga gerbang'. Sebelum kode baru masuk ke develop atau main, kita pastikan dulu dia lolos semua tes dan pemeriksaan kualitas. Kalau gagal, PR-nya bisa ditahan dulu sampai diperbaiki. Canggih, kan?

Jadi, dengan trigger ini, kita memastikan proses pengecekan otomatis berjalan di momen-momen krusial: saat ada kode baru masuk ke branch utama/pengembangan, dan saat ada usulan penggabungan kode (PR) ke branch tersebut.

3. `jobs:` - Daftar Tugas Buat Si Asisten

Setelah kita tentukan kapan si asisten GitHub Actions harus kerja (lewat on:), sekarang kita kasih tahu apa saja pekerjaan yang harus dia lakukan. Nah, daftar pekerjaan ini kita definisikan di dalam blok jobs:.

# ... (name dan on)

jobs:
  ci:
    runs-on: ubuntu-latest
    container:
      image: ramaid/image:php8.4-fullstack-cli-v2.5.0
      options: --user root
      volumes:
        - /run/docker:/run/docker

    steps:
      # ... (langkah-langkah detail akan dibahas nanti)

Di dalam jobs:, kita bisa mendefinisikan satu atau lebih job. Setiap job adalah satu set langkah (steps) yang akan dijalankan di runner (lingkungan eksekusi). Di contoh ini, kita punya satu job utama yang diberi nama ci:

ci: - Nama Pekerjaan Utama Kita Sama seperti name: Tests tadi, ci: ini hanyalah nama yang kita berikan untuk job ini. Bisa saja dinamai build_and_test, validation, atau nama lain yang deskriptif. Nama ci (singkatan dari Continuous Integration) cukup umum dipakai untuk job yang tugasnya melakukan build, test, dan analisa kode.

Selanjutnya, di dalam job ci: ini, kita tentukan di mana dan bagaimana si asisten harus bekerja:

runs-on: ubuntu-latest - "Tolong Kerjakan di Komputer Linux Ubuntu Ya!"
- Apa itu runner? Anggap saja runner ini seperti komputer atau server virtual yang disiapkan oleh GitHub (atau bisa juga kita siapkan sendiri) khusus untuk menjalankan job kita.
- runs-on: ubuntu-latest berarti kita minta GitHub untuk menjalankan job ci ini di atas runner yang menggunakan sistem operasi Linux Ubuntu versi terbaru yang tersedia di GitHub Actions.
- Kenapa pilih ubuntu-latest? Ini pilihan paling umum dan seringkali jadi default. Ubuntu banyak dipakai di server, tools pengembangan juga melimpah di Linux, jadi biasanya aman dan kompatibel untuk banyak jenis proyek, termasuk web development pakai PHP dan Node.js/Bun seperti kasus kita. GitHub juga menyediakan runner Windows dan macOS kalau memang dibutuhkan.
container: - "Kerjainnya di Dalam 'Kontainer' Khusus Ini Ya!" Nah, ini bagian yang menarik! Alih-alih langsung menjalankan perintah di ubuntu-latest, kita minta si runner Ubuntu untuk menjalankan semua langkah (steps) di dalam sebuah kontainer Docker.
- Apa itu Kontainer (Docker)? Bayangin kontainer itu kayak 'kotak ajaib' yang udah diisi lengkap sama semua software, library, dan konfigurasi spesifik yang dibutuhkan aplikasi kita buat jalan. Keuntungannya? Lingkungan kerja jadi super konsisten. Mau dijalankan di laptop kamu, di komputer temanmu, atau di runner GitHub Actions, hasilnya bakal sama persis karena 'kotak ajaib'-nya sama. Ini membantu menghindari masalah klasik "loh, di laptop saya jalan kok!".
- image: ramaid/image:php8.4-fullstack-cli-v2.5.0 - Pakai Image Buatan Sendiri!
  - Di sini kita nggak pakai image Docker standar (kayak php:8.4-cli atau node:20), tapi pakai custom image yang namanya ramaid/image:php8.4-fullstack-cli-v2.5.0. Ini kemungkinan besar adalah image Docker yang sudah disiapkan khusus oleh Mas Qisthi (dilihat dari nama ramaid/).
  - Keuntungannya pakai custom image apa? Gede banget! Di dalam image ini kemungkinan sudah ter-install semua yang dibutuhkan project Catalystack: Versi PHP yang pas (8.4), Composer, ekstensi PHP yang diperlukan (misal pdo_mysql, gd, xdebug), Node.js atau Bun (karena nanti ada bun install), mungkin juga tools lain kayak Git, sonar-scanner, dll. Jadi, pas workflow jalan, kita nggak perlu lagi buang waktu install ini-itu di awal. Semuanya udah siap pakai! Ini bikin proses CI jadi lebih cepat dan lebih reliable. Keren, kan? 👍
- options: --user root - Jadi 'Super User' Sebentar
  - Opsi ini ngasih tahu Docker untuk menjalankan perintah di dalam kontainer sebagai user root (administrator tertinggi di Linux).
  - Kenapa butuh root? Kadang-kadang, ada beberapa perintah (misal install package sistem, mengubah permission file tertentu, atau interaksi dengan Docker daemon itu sendiri) yang butuh hak akses root. Meskipun sebaiknya dihindari jika tidak perlu karena alasan keamanan, tapi dalam konteks CI di lingkungan terkontrol seperti kontainer, ini kadang jadi solusi praktis. Mungkin image ramaid/image ini butuh akses root untuk beberapa operasinya.
- volumes: - /run/docker:/run/docker - Berbagi 'Soket' Docker
  - Bagian ini sedikit lebih teknis. volumes: digunakan untuk 'memasang' (mount) folder dari runner (host) ke dalam kontainer.
  - - /run/docker:/run/docker secara spesifik mencoba memetakan socket Docker dari runner ke dalam kontainer.
  - Buat apa? Ini biasanya diperlukan kalau di dalam job GitHub Actions kita (yang sudah berjalan di dalam kontainer), kita perlu menjalankan perintah Docker lagi (misalnya buat build image lain atau menjalankan service tambahan). Ini sering disebut teknik "Docker-in-Docker" (meskipun cara ini lebih ke "Docker-out-of-Docker" karena pakai socket dari host). Kemungkinan di salah satu step nanti (atau mungkin di script internal image), ada kebutuhan untuk berinteraksi dengan Docker daemon.

Jadi, dengan konfigurasi jobs, runs-on, dan container ini, kita sudah menyiapkan 'panggung' yang sangat spesifik dan optimal untuk menjalankan langkah-langkah CI project Catalystack: di atas Ubuntu terbaru, tapi di dalam sebuah kontainer Docker custom yang sudah lengkap isinya, dan siap jika perlu interaksi lebih lanjut dengan Docker. steps: - Langkah-langkah Detail yang Harus Dikerjakan

Di bawah container:, kita temukan blok steps:. Ini adalah jantung dari job ci kita. Setiap item di bawah steps: adalah satu tugas spesifik yang akan dijalankan secara berurutan. Yuk, kita ikuti perjalanannya!

# ... (jobs, ci, runs-on, container)

steps:
  - name: Checkout
    uses: actions/checkout@v4
    with:
      # Fetch all history for all branches and tags
      fetch-depth: 0

  - name: Install Dependencies
    run: composer install --no-interaction --prefer-dist --optimize-autoloader

  - name: Setup Environment
    run: |
      cp .env.example .env
      php artisan migrate --force
      php artisan key:generate
      php artisan wayfinder:generate

  - name: Build Assets
    run: |
      bun install
      bun run build

  - name: Tests
    run: |
      XDEBUG_MODE=coverage php artisan test --coverage \
        --coverage-clover=coverage.xml \
        --log-junit=results.xml

  - name: SonarCloud Scan
    uses: SonarSource/sonarqube-scan-action@v5
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

  - name: Sonar Scan Self Hosted
    env:
      SONAR_TOKEN: ${{ secrets.SONAR_MC_TOKEN }}
    run: |
      sonar-scanner -Dsonar.token=$SONAR_TOKEN -Dsonar.host.url=http://sonar.malescast.tech/

Langkah 1: `name: Checkout` - Ambil Kode Dulu!

name: Checkout: Lagi-lagi, ini cuma label biar gampang dibaca di log GitHub Actions. Isinya jelas: "Langkah untuk mengambil kode".
uses: actions/checkout@v4: Di sini kita nggak pakai run: untuk menjalankan perintah manual, tapi pakai uses:. Ini artinya kita menggunakan sebuah 'Action' (alat bantu siap pakai) yang sudah disediakan. actions/checkout@v4 adalah Action resmi dari GitHub yang tugasnya simple tapi penting: mengunduh kode dari repository kita ke dalam runner (atau dalam kasus ini, ke dalam kontainer yang berjalan di runner). Tanpa kode, ya kita nggak bisa ngapa-ngapain, kan? 😁
with: fetch-depth: 0: Ini adalah opsi tambahan untuk Action checkout. Secara default, checkout mungkin hanya mengambil kode versi terakhir saja untuk efisiensi. Tapi dengan fetch-depth: 0, kita minta dia untuk mengambil seluruh riwayat (history) commit dari semua branch dan tag.
- Kenapa butuh semua history? Ini penting banget buat tools analisa kode seperti SonarQube/SonarCloud. Mereka seringkali butuh melihat riwayat perubahan untuk bisa menganalisa kapan suatu isu muncul, siapa yang mengenalkannya, dan metrik-metrik lainnya secara lebih akurat. Jadi, meskipun sedikit lebih lama pas checkout, ini worth it untuk hasil analisa yang lebih baik.

Langkah 2: `name: Install Dependencies` - Pasang 'Perkakas' PHP (Composer)

name: Install Dependencies: Label lagi, artinya "Pasang dependensi/kebutuhan proyek".
run: composer install --no-interaction --prefer-dist --optimize-autoloader: Nah, ini pakai run: karena kita menjalankan perintah langsung di shell kontainer.
- composer install: Ini perintah inti untuk Composer, si manajer paket paling populer di dunia PHP/Laravel. Perintah ini akan membaca file composer.json dan composer.lock di project kamu, lalu mengunduh dan memasang semua library PHP pihak ketiga yang dibutuhkan (misal framework Laravel itu sendiri, library untuk database, API, dll).
- --no-interaction: Opsi ini penting untuk otomatisasi. Artinya, kalau ada pertanyaan atau pilihan saat proses instalasi (misal "Do you want to remove existing VCS history?"), Composer nggak akan nunggu jawaban kita, tapi akan pakai pilihan default-nya. Di CI, nggak ada orang yang bisa jawab, kan? 🤖
- --prefer-dist: Opsi ini minta Composer untuk sebisa mungkin mengunduh versi paket dalam bentuk arsip .zip (distribusi) yang sudah jadi, daripada mengunduh langsung dari repository Git-nya (--prefer-source). Biasanya ini lebih cepat dan cocok untuk CI atau production.
- --optimize-autoloader: Setelah semua paket terpasang, Composer akan membuat file autoloader (semacam 'peta' biar PHP tahu di mana lokasi class-class). Opsi ini akan mengoptimalkan 'peta' tersebut biar aplikasi Laravel kita bisa me-load class dengan lebih cepat saat dijalankan. Nice optimization!
- (Ingat: Semua ini bisa jalan karena di dalam kontainer ramaid/image tadi sudah terpasang Composer dan PHP 8.4!)

Langkah 3: `name: Setup Environment` - Siapin 'Meja Kerja' Laravel

name: Setup Environment: Label untuk langkah persiapan lingkungan spesifik Laravel.
run: |: Tanda | ini artinya kita mau menjalankan beberapa perintah shell sekaligus dalam satu langkah.
- cp .env.example .env: Di setiap project Laravel, biasanya ada file .env.example yang berisi contoh variabel konfigurasi (koneksi database, API key, dll). Kita nggak boleh menyimpan file .env asli (yang berisi credential rahasia) di Git. Nah, di CI, kita perlu file .env ini biar aplikasi bisa jalan (terutama untuk konek ke database saat testing nanti). Jadi, kita salin aja dari contohnya. Untuk CI, biasanya kita pakai konfigurasi khusus testing (misal database SQLite in-memory). Konfigurasi ini mungkin sudah diatur di .env.example atau perlu di-override lagi nanti.
- php artisan migrate --force: php artisan adalah command-line tool bawaan Laravel. Perintah migrate digunakan untuk menjalankan database migration, yaitu script yang membuat atau mengubah struktur tabel di database sesuai definisi di kode kita. --force diperlukan agar perintah ini jalan di lingkungan non-interaktif (CI/production) tanpa minta konfirmasi "Yakin mau dijalankan?".
- php artisan key:generate: Perintah ini akan membuat Application Key (APPKEY) unik di file .env. Kunci ini dipakai Laravel untuk enkripsi sesi, _cookie, dan hal-hal sensitif lainnya. Wajib hukumnya punya kunci ini biar aplikasi aman!
- php artisan wayfinder:generate: Nah, perintah ini nggak ada di Laravel standar. Ini kemungkinan besar adalah perintah custom yang dibuat khusus untuk project Catalystack. Mungkin fungsinya untuk men-generate sitemap, route list, atau konfigurasi spesifik lain yang dibutuhkan project ini. (Mas Qisthi yang lebih tahu detailnya! 😉)

Langkah 4: `name: Build Assets` - Siapin 'Tampilan' React (Bun)

name: Build Assets: Label untuk proses persiapan aset frontend.
run: |: Lagi-lagi, beberapa perintah sekaligus.
- bun install: Karena Catalystack pakai React untuk frontend, kita juga perlu install dependensi JavaScript-nya. Di sini, terlihat project ini menggunakan Bun, sebuah runtime dan toolkit JavaScript modern yang dikenal super cepat (alternatif dari Node.js + npm/yarn). Perintah bun install mirip npm install atau yarn install, yaitu membaca package.json dan memasang semua library JavaScript yang dibutuhkan (React, dan kawan-kawannya). (Ini juga bisa jalan karena kontainer ramaid/image sudah disiapkan dengan Bun terinstall).
- bun run build: Setelah dependensi terpasang, perintah ini akan menjalankan script build yang biasanya didefinisikan di package.json. Untuk project React (biasanya pakai tools seperti Vite atau Create React App), proses build ini akan mengubah kode React (JSX), JavaScript modern (ES6+), CSS/Sass/Tailwind, dll, menjadi file-file HTML, CSS, dan JavaScript statis yang sudah dioptimasi (di-minify, di-bundle) dan siap disajikan ke browser pengguna. Hasilnya biasanya ditaruh di folder dist atau build.

Langkah 5: `name: Tests` - Uji Coba Kode Laravel!

name: Tests: Label paling penting: waktunya pengujian!
run: |: Perintah pengujiannya.
- XDEBUG_MODE=coverage php artisan test ...: Ini dia eksekusi utamanya. Kita pakai lagi php artisan, kali ini dengan perintah test untuk menjalankan automated tests yang sudah ditulis (biasanya pakai PHPUnit, testing framework standar di Laravel).
- XDEBUG_MODE=coverage: Ini adalah cara untuk mengaktifkan fitur code coverage dari Xdebug (sebuah ekstensi PHP populer untuk debugging dan profiling). Dengan mode ini aktif, saat test berjalan, Xdebug akan mencatat baris kode mana saja yang dieksekusi oleh test tersebut. (Lagi-lagi, ini butuh Xdebug terinstall dan terkonfigurasi di dalam kontainer ramaid/image).
- --coverage: Opsi ini memberitahu artisan test (PHPUnit) bahwa kita ingin mengumpulkan data code coverage.
- --coverage-clover=coverage.xml: Opsi ini meminta PHPUnit untuk menghasilkan laporan coverage dalam format Clover XML dan menyimpannya ke file coverage.xml. Format Clover ini umum dipakai dan bisa dibaca oleh banyak tools lain, termasuk SonarQube/SonarCloud.
- --log-junit=results.xml: Opsi ini meminta PHPUnit untuk menyimpan hasil detail setiap test (sukses, gagal, error, waktu eksekusi) dalam format JUnit XML ke file results.xml. Format JUnit juga merupakan standar de facto di dunia CI/CD untuk melaporkan hasil testing.

Langkah 6: `name: SonarCloud Scan` - Cek Kualitas Kode (Otomatis!) via SonarCloud

name: SonarCloud Scan: Label untuk analisa kualitas kode menggunakan layanan SonarCloud.
uses: SonarSource/sonarqube-scan-action@v5: Kita pakai Action resmi lagi, kali ini dari SonarSource (pembuat SonarQube & SonarCloud). Action ini memudahkan kita mengirim hasil analisa ke SonarCloud.
env:: Di sini kita mendefinisikan environment variable yang dibutuhkan oleh Action SonarSource.
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}: Token ini otomatis disediakan oleh GitHub Actions. Biasanya dipakai SonarCloud untuk mengambil informasi dari repository atau memberikan komentar di Pull Request jika ada isu kualitas kode. secrets.GITHUB_TOKEN adalah cara aman untuk mengakses token ini tanpa menuliskannya langsung di kode.
- SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}: Ini adalah token otentikasi khusus dari akun SonarCloud kamu. Token ini sangat rahasia dan harus disimpan di Secrets GitHub (Pengaturan > Secrets and variables > Actions). Action ini akan menggunakannya untuk otentikasi saat mengirim laporan ke project SonarCloud yang sesuai.
- Bagaimana cara kerjanya? Action ini secara cerdas akan mencari file konfigurasi SonarQube (biasanya sonar-project.properties) di root project kamu, menemukan laporan coverage (coverage.xml) dan laporan test (results.xml - jika dikonfigurasi), lalu menjalankan analisa dan mengirim semuanya ke SonarCloud.

Langkah 7: `name: Sonar Scan Self Hosted` - Cek Kualitas Kode (Lagi!) ke Server Sendiri

name: Sonar Scan Self Hosted: Label untuk analisa kedua, kali ini ke server SonarQube yang di-hosting sendiri.
env: SONAR_TOKEN: ${{ secrets.SONAR_MC_TOKEN }}: Token otentikasi lagi, tapi kali ini berbeda (SONAR_MC_TOKEN). Ini juga harus disimpan di Secrets GitHub dan merupakan token untuk mengakses server SonarQube di sonar.malescast.tech.
run: |: Menjalankan perintah shell.
- sonar-scanner -Dsonar.token=$SONAR_TOKEN -Dsonar.host.url=http://sonar.malescast.tech/: Di sini kita tidak pakai Action, tapi menjalankan tool sonar-scanner langsung dari command line. (Ini mengasumsikan sonar-scanner sudah terinstall di kontainer ramaid/image).
  - -Dsonar.token=$SONAR_TOKEN: Kita memberikan token otentikasi yang sudah disimpan di environment variable SONAR_TOKEN.
  - -Dsonar.host.url=http://sonar.malescast.tech/: Kita secara eksplisit memberitahu sonar-scanner alamat URL dari server SonarQube self-hosted yang akan menerima laporan analisa.
- Sama seperti Action SonarCloud, sonar-scanner juga akan mencari file konfigurasi (sonar-project.properties), laporan coverage, dan laporan test, lalu mengirimkannya ke server tujuan.
- Kenapa ada dua scan? Mungkin ada beberapa alasan. Bisa jadi tim ingin membandingkan hasil analisa di Cloud vs Self-hosted, atau mungkin ada kebijakan internal yang mengharuskan analisa di server sendiri, sementara SonarCloud dipakai untuk integrasi publik/GitHub.

Fiuh! Panjang juga ya perjalanan kita membedah steps: ini. Tapi sekarang jadi jelas kan tiap langkahnya ngapain aja? Dari ambil kode, pasang dependensi PHP & JS, siapin environment Laravel, build aset React, jalanin test + coverage, sampai kirim laporan kualitas kode ke SonarCloud dan SonarQube self-hosted. Semuanya berjalan otomatis! ✨

Penutup: Otomatis Itu Keren!

Gimana, guys? Keren banget kan gimana kita bisa 'menyuruh' GitHub Actions buat ngerjain semua tugas repetitif tapi krusial kayak install dependencies, setup environment, build assets, testing, sampai analisa kualitas kode pakai SonarQube/SonarCloud? Semuanya otomatis, tinggal push atau bikin PR, lalu duduk manis (atau lanjut ngoding fitur lain 😉).

Dengan setup CI seperti yang kita bedah di project Catalystack (Laravel 12 + React) ini, kita bisa dapetin banyak banget keuntungan:

Kode Lebih Berkualitas: Potensi bug dan isu keamanan bisa ketahuan lebih awal lewat testing otomatis dan analisa SonarQube.
Lebih Pede Saat Rilis: Karena setiap perubahan udah diuji, kita jadi lebih yakin kalau aplikasi kita stabil.
Kerja Tim Lebih Efisien: Proses integrasi kode jadi lebih standar dan nggak makan waktu buat pengecekan manual.
Hemat Waktu & Tenaga: Biarkan robot yang kerja keras, kita fokus ke hal-hal yang lebih seru: bikin fitur!

Tips Tambahan & Langkah Berikutnya:

Setelah berhasil setup CI ini, jangan berhenti di situ! Ada beberapa hal lagi yang bisa kamu eksplorasi:

Pantau Hasilnya: Rajin-rajin cek tab "Actions" di GitHub buat lihat status workflow-nya. Kalau ada yang merah (gagal), segera investigasi. Jangan lupa juga intip dashboard SonarCloud atau SonarQube kamu buat lihat laporan detail kualitas kode dan test coverage-nya. Angka coverage di atas 80% itu udah bagus banget!
Tambahin Linting: Biar kode makin rapi dan konsisten, kamu bisa tambahin langkah buat linting (cek gaya penulisan kode). Untuk PHP bisa pakai PHP_CodeSniffer atau PHP-CS-Fixer, untuk JavaScript/React bisa pakai ESLint atau Prettier.
Notifikasi: Biar makin real-time, kamu bisa setting GitHub Actions buat kirim notifikasi ke Slack, Telegram, atau Discord setiap kali ada build yang gagal atau sukses.
Lanjut ke CD (Continuous Deployment): Kalau CI-nya udah mantap, langkah selanjutnya adalah Continuous Deployment. Kamu bisa bikin workflow lain yang otomatis men-deploy aplikasi ke server staging atau bahkan production setiap kali ada push ke branch tertentu (misal main) dan semua tes lolos. Tapi hati-hati ya kalau mau otomatisasi deploy ke production!

Dunia CI/CD itu luas banget dan selalu berkembang. Setup yang kita bahas di sini adalah salah satu contoh implementasi yang solid untuk project Laravel + React.

Selamat mencoba dan selamat ngoding dengan lebih otomatis! 🚀

Otomatisasi Testing & Analisa Kode Laravel + React dengan GitHub Actions & SonarQube

Kenalan Sama GitHub Actions: Si Asisten Otomatis di GitHub

Sekilas Project Catalystack & Kebutuhan Otomatisasi

1. name: Tests - Kasih Nama Biar Nggak Bingung

2. on: - Kapan Si Asisten Mulai Kerja? (Trigger)

3. jobs: - Daftar Tugas Buat Si Asisten

1. `name: Tests` - Kasih Nama Biar Nggak Bingung

2. `on:` - Kapan Si Asisten Mulai Kerja? (Trigger)

3. `jobs:` - Daftar Tugas Buat Si Asisten