Semua disiplin section ini — format baku, linter, doc test — bertumpu pada satu asumsi rapuh: bahwa setiap orang menjalankan cargo fmt, cargo clippy, dan cargo test sebelum mengirim kode. Kenyataannya manusia lupa, tergesa, atau meyakini kodenya sudah bersih tanpa memeriksanya. Continuous Integration (CI) menghapus asumsi tersebut: server otomatis menjalankan seluruh pemeriksaan setiap kali kode terdorong atau pull request dibuka, dan hasilnya berstatus jelas — hijau berarti semua lolos, merah berarti ada yang harus diperbaiki sebelum digabung. GitHub Actions adalah layanan CI bawaan GitHub yang cukup populer untuk proyek Rust; konfigurasinya ditulis sebagai file YAML di dalam repository itu sendiri. Chapter penutup section ini merangkai seluruh alat yang telah kita kuasai menjadi satu workflow, membedah setiap langkahnya, dan menjelaskan dengan jujur apa yang terjadi saat workflow berjalan — termasuk batas apa yang bisa kita buktikan di lingkungan belajar ini.

Masalah: Kualitas yang Bergantung pada Ingatan #

Tanpa CI, gerbang kualitas hidup di mesin masing-masing kontributor. Konsekuensinya mudah ditebak: satu commit lupa diformat, satu pull request lolos dengan warning clippy, satu test gagal tanpa diketahui pemilik branch lain. Masalah bukan pada orangnya, melainkan pada posisi pemeriksaan: pemeriksaan yang berada di mesin pengembang bersifat opsional, sedangkan pemeriksaan di server bersifat wajib — kode yang gagal tidak bisa menyamar sebagai lolos. Memindahkan ketiga perintah kualitas ke CI juga memberi manfaat kedua: seluruh tim melihat standar yang sama, dijalankan pada lingkungan bersih yang sama, pada versi Rust yang sama.

Mekanisme: Workflow, Runner, dan Langkah Berurutan #

GitHub Actions membaca file YAML di folder .github/workflows/ — setiap file mendeskripsikan satu workflow. Bagian on menentukan trigger: event apa yang menyalakan workflow, misalnya push ke branch tertentu atau pembukaan pull_request baru. Saat trigger terjadi, GitHub menyediakan mesin virtual sementara yang disebut runner (label ubuntu-latest meminta runner Linux) dan menjalankan job di dalamnya. Setiap job terdiri atas steps yang berjalan berurutan dari atas ke bawah; bila satu step gagal — exit code bukan nol — job berhenti di step tersebut dan seluruh workflow ditandai gagal. Step bisa berisi perintah shell (run:) atau pemakaian action pihak ketiga (uses:) — action adalah modul siap pakai, misalnya untuk menyalin isi repository atau memasang toolchain.

Contoh: Workflow CI untuk Proyek Rust #

Buat folder .github/workflows/ di root proyek, lalu simpan file ci.yml berikut:

yaml 
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  kualitas:
    runs-on: ubuntu-latest
    steps:
      - name: Ambil kode dari repository
        uses: actions/checkout@v4

      - name: Pasang toolchain Rust stabil
        uses: dtolnay/rust-toolchain@stable
        with:
          components: rustfmt, clippy

      - name: Cek format kode
        run: cargo fmt --check

      - name: Jalankan clippy
        run: cargo clippy -- -D warnings

      - name: Jalankan test
        run: cargo test

Mari kita bedah file tersebut baris per baris:

  1. Baris 1 (name: CI): nama workflow yang tampil di tab Actions GitHub dan pada status check setiap pull request.
  2. Baris 3-6 (on: push: branches: [main] dan pull_request:): trigger ganda — setiap push ke branch main dan setiap pull request ke repository mana pun arahnya memicu workflow. Pull request adalah titik terpentingnya karena status CI tampil langsung di halaman review.
  3. Baris 8-9 (jobs: kualitas: dan runs-on: ubuntu-latest): job bernama kualitas dijalankan pada runner Linux. Runner selalu mulai kosong — tiap eksekusi dapat mesin virtual baru, itulah yang menjamin hasil konsisten dan bebas dari sisa instalasi di mesin lokal.
  4. Baris 11 (uses: actions/checkout@v4): action resmi yang menyalin isi repository ke runner. Tanpa langkah ini, folder proyek di runner kosong dan cargo tidak punya apa pun untuk diperiksa.
  5. Baris 14-16 (uses: dtolnay/rust-toolchain@stable ... components: rustfmt, clippy): action komunitas yang memasang toolchain Rust stabil beserta komponen rustfmt dan clippy — keduanya tidak terpasang bawaan di runner, sama seperti di mesin lokal. Versi major action ditandai @v4 atau @stable.
  6. Baris 19 (run: cargo fmt --check): perintah pertama kita dari Chapter rustfmt Dasar. Opsi --check menjadikannya pemeriksa murni: bila ada file yang belum terformat, perintah mencetak diff dan keluar dengan exit code bukan nol, sehingga step gagal dan workflow berhenti.
  7. Baris 22 (run: cargo clippy -- -D warnings): perintah clippy dengan deny seluruh warning — satu warning sekalipun menggagalkan step, sesuai disiplin dari Chapter clippy Dasar.
  8. Baris 25 (run: cargo test): menjalankan seluruh suite — unit test, integration test, dan doc test — satu perintah yang menguji documentation sekaligus logika, sesuai materi section testing dan dokumentasi.

Urutan ketiganya disusun dari pemeriksaan paling murah ke paling mahal: format diperiksa tanpa kompilasi penuh, clippy mengompilasi tanpa menghasilkan binary, dan test menjalankan program sungguhan. Kegagalan dini di step murah menghemat waktu runner.

Apa yang Terjadi Saat Workflow Berjalan #

Sekarang bagian yang harus kita sampaikan dengan jujur: workflow di atas tidak dijalankan di lingkungan materi ini, karena tidak ada repository GitHub yang terhubung — memeriksa eksekusi CI sungguhan membutuhkan push ke repository nyata. Yang bisa kita lakukan di sini adalah memverifikasi bahwa perintah-perintah di dalam setiap step benar-benar lolos pada kode contoh, dan bahwa file YAML valid. Kedua hal tersebut telah diuji: ketiga perintah dijalankan lokal pada proyek contoh dan lulus, dan struktur file YAML telah lolos pemeriksaan parser.

Pada repository nyata, pola eksekusinya berjalan seperti ini: begitu pull request dibuka, GitHub memprovision runner, workflow berjalan, dan halaman pull request menampilkan status tiap step — nama step dari kolom name: tampil sebagai daftar periksa. Jika semua step lolos, status berwarna hijau dan branch dianggap siap direview. Jika cargo fmt --check menemukan file yang belum terformat, step “Cek format kode” berhenti dengan tanda silang, log step menampilkan diff yang persis seperti keluaran lokal kita di Chapter rustfmt Dasar, dan dua step setelahnya tidak dijalankan. Penulis pull request tinggal menjalankan cargo fmt di lokal, commit perubahan, dan push — push baru memicu workflow lagi. Perbaikan tidak perlu menebak; log CI selalu menunjukkan perintah mana yang gagal dan keluaran lengkapnya.

Verifikasi Lokal Sebelum Push #

Kegagalan CI yang paling membuang waktu adalah kegagalan yang bisa kita temukan lebih dulu. Sebelum push, ketiga perintah yang sama bisa dijalankan berurutan di lokal. Pada proyek contoh berikut — fungsi pembuat label kemasan dengan satu unit test:

rust 
fn buat_label(nama: &str, berat_gram: u32) -> String {
    format!("label {nama} — {berat_gram} gram")
}

fn main() {
    println!("{}", buat_label("Kopi Senja", 250));
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn label_memuat_nama_dan_berat() {
        assert_eq!(buat_label("Kopi Senja", 250), "label Kopi Senja — 250 gram");
    }
}

Jalankan ketiga pemeriksaan di lokal:

bash 
cargo fmt --check
cargo clippy -- -D warnings
cargo test

Output yang Dihasilkan (step test — keluaran lengkap):

text 
     Running unittests src/main.rs (target/debug/deps/label-602213a697e0d50c)

running 1 test
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Perintah pertama keluar tanpa keluaran apa pun — tidak ada file yang perlu diformat. Perintah kedua hanya mencetak baris Checking dan Finished, artinya clippy menemukan nol warning. Laporan cargo test menunjukkan satu test lulus. Ketiga hasil inilah yang diharapkan muncul hijau pada tiap step workflow di GitHub.

Ringkasan #

Workflow GitHub Actions di .github/workflows/ci.yml mengubah cargo fmt --check, cargo clippy -- -D warnings, dan cargo test dari kebiasaan opsional menjadi gerbang wajib: trigger push dan pull_request menyalakan job pada runner Linux bersih, langkah berjalan berurutan dan berhenti pada kegagalan pertama, dan status tampil langsung di halaman pull request. Action checkout menyalin repository, action dtolnay/rust-toolchain@stable memasang Rust beserta komponen rustfmt dan clippy, lalu ketiga perintah kualitas kita berjalan persis seperti di lokal — ketiganya telah diverifikasi lolos pada proyek contoh. Dengan ini section Kualitas Kode tertutup: format, lint, dan test kini dijaga oleh mesin, bukan oleh ingatan.