Untuk mengintegrasikan GuixPkgs lewat Nix Flake ke workflow CI/CD, langkah pertama adalah menjadikan setiap paket Guix dapat dipanggil sebagai input flake. Setelah struktur flake siap, pipeline CI/CD bisa langsung menggunakan dependency yang didapat dari Guix, menjaga konsistensi lingkungan pengembangan dan produksi.

Artikel ini menunjukkan cara menyiapkan flake, menyinkronkan dependensi, memasukkan linting/build automation, serta menentukan strategi release yang memanfaatkan Guix sebagai referensi sumber paket. Langkah-langkah dijabarkan berdasarkan praktik nyata agar tim pengembang dapat mengadopsinya dengan lebih mudah.

Menyiapkan Flake GuixPkgs

Referensi https://fzakaria.com/2026/06/25/guixpkgs-every-guix-package-as-a-nix-flake menjelaskan pendekatan membuat GuixPkgs tersedia sebagai flake Git. Yang diperlukan adalah menjadikan Guix sebagai input flake dalam file flake.nix, lalu memetakan paket yang dibutuhkan. Contoh struktur sederhana:

{ inputs ? { } }:
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    guixpkgs.url = "github:guix-patches/guixpkgs"; # Fork yang menjadi flake
    guix-to-nix.url = "github:guix-patches/guix-to-nix";
  };

  outputs = { self, nixpkgs, guixpkgs, guix-to-nix, ... }:
    let
      guix = guix-to-nix.defaultGuixPackages;
    in {
      devShells.x86_64-linux.default = nixpkgs.lib.mkShell {
        buildInputs = [ guix.git guix.packages.gcc ];
      };
    };
}

Di sini, guix-to-nix digunakan untuk mengekspos paket Guix sebagai atribut yang bisa dipakai dalam flake. Anda bisa mengadaptasi atribut ini menjadi callPackage atau mkShell sesuai kebutuhan.

Pastikan repo Guix yang dipakai mendukung flake dan memperbaharui flake lock file bila input berubah. Gunakan nix flake update saat memperbarui sumber paket agar CI/CD selalu mengunci revisi yang sama.

Sinkronisasi Dependensi untuk CI/CD

Untuk menjaga pipeline tetap reproduktif, pastikan setiap runner CI memuat flake lock yang sama. Langkah praktisnya:

  1. Commit flake.lock setelah nix flake update dan jangan hapus manual.
  2. Gunakan nix develop atau nix build dengan --impure hanya jika benar-benar diperlukan.
  3. Di CI, autentikasi cache dan store path sebaiknya diselaraskan dengan nix.conf untuk mengizinkan binary cache private.

Contoh job GitHub Actions:

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Nix
        uses: cachix/install-nix-action@v18
      - name: Restore cache
        run: nix build .#devShells.x86_64-linux.default

Job ini memastikan runner menggunakan definisi shell yang sama dengan developer lokal. Tambahan caching (misalnya Cachix) mempercepat build karena paket Guix yang sudah dibangun dapat diunduh langsung.

Integrasi Linting dan Build Automation

Gunakan paket Guix yang terkait linting sebagai bagian buildInputs flake. Misalnya, jika Anda memakai language server atau bundler linting khusus Guix:

buildInputs = [ guix.packages.clang-format guix.packages.shellcheck ];

Selanjutnya, definisikan command dalam flake.nix agar linting bisa dipanggil dari CI:

checks.x86_64-linux = builtins.mapAttrsToList (name: package: {
  name = name;
  script = "${package}/bin/shellcheck scripts/*.sh";
}) { shellcheck = guix.packages.shellcheck; };

Mengintegrasikan checking ini ke pipeline berarti Anda tidak perlu menginstal alat secara terpisah di runner; cukup jalankan nix flake check atau nix build .#checks.x86_64-linux untuk memicu seluruh suite lint/build.

Strategi Release dan Caching

Release pipeline harus memastikan binary cache atau derivation disediakan kembali untuk deployment. Strategi yang bisa diterapkan:

  • Build once, deploy everywhere: Output dari nix build .#packages.x86_64-linux.my-app disimpan ke cache publik atau privat (misalnya Cachix).
  • Tag release dengan flake lock: Saat membuat release Git, sertakan flake.lock yang menunjuk revisi Guix yang konsisten.
  • Cache Guix store: Tambahkan konfigurasi substituters = https://cache.nixos.org https://my-cache dan trusted-public-keys di nix.conf supaya runner bisa mengambil derivation Guix yang sudah dibangun.

Perhatikan bahwa Guix memiliki model store tersendiri; menjaga kedua cache (Nix dan Guix) konsisten menjadi tantangan, tetapi dependency yang diekspor sebagai flake menyederhanakan hal ini.

Perbandingan dengan Pendekatan Nix Konvensional

Penggunaan GuixPkgs lewat Nix Flake berbeda dari menggunakan pure Nix karena:

  • Konsistensi paket: Guix mengelola dependency lewat guile dan menyediakan paket yang mungkin tidak ada di nixpkgs.
  • Ketersediaan versi: Anda bisa menyertakan paket Guix spesifik yang belum dijemput oleh nixpkgs.
  • Kompleksitas kontribusi: Flake perlu menyertakan bridge guix-to-nix, sementara pendekatan Nix biasa cukup merujuk ke nixpkgs.

Gunakan pendekatan Guix ketika Anda membutuhkan paket unik atau fasilitas Guix (misalnya garbage collection bawaan). Untuk proyek yang sudah bergantung berat pada nixpkgs dan tidak membutuhkan paket tambahan, tetap pada Nix murni bisa lebih sederhana.

Automatisasi Pembaruan Paket

Untuk menjaga update tetap terkelola, manfaatkan tool seperti nix flake update --update-input guixpkgs secara terjadwal (misalnya GitHub Action atau Cron). Demonstrasi langkah otomatisasi:

  1. Jalankan script CI yang memeriksa perbedaan flake.lock setelah update.
  2. Jika berubah, buat PR otomatis dengan nix flake update --update-input guixpkgs.
  3. Gunakan action yang menjalankan nix flake check sebelum merge untuk memastikan paket baru tidak merusak pipeline.

Juga penting menyiapkan peringatan bila paket Guix tidak bisa dibangun pada runner tertentu—pantau log nix log atau guix build untuk menemukan dependency yang gagal.

Debugging dan Kesalahan Umum

Beberapa hal yang perlu diperhatikan:

  • Kesalahan flake.lock out-of-sync: Jalankan nix flake lock --recreate bila isi repositorinya berubah secara signifikan.
  • Ketergantungan Guix tidak ditemukan: Pastikan atribut yang dipanggil memang tersedia di overlay Guix, dan periksa log guix build.
  • Cache tidak digunakan: Periksa konfigurasi trusted-public-keys dan substituters agar runner dapat mengambil binary dari cache eksternal.

Dengan langkah-langkah tersebut, workflow CI/CD dapat memanfaatkan ekosistem Guix melalui interface Nix Flake tanpa meninggalkan kemudahan reproduktibilitas yang sudah ada di Nix.