Linting menjadi bottleneck bila pipeline CI harus memuat ulang config, plugin, dan lingkungan setiap kali dijalankan. Optimasi cache artefak linting meminimalkan waktu setup dengan memanfaatkan hash konfigurasi dan dependensi, sehingga feedback linting tetap cepat tanpa mengorbankan akurasi.

Peningkatan throughput linting di pipeline CI

Linting umumnya membaca banyak file konfigurasi (eslintrc, pyproject, stylelint), plugin, dan cache build (seperti .eslintcache). Semakin besar tim, pipeline linting bisa mendominasi waktu CI karena instalasi ulang dependensi dan parsing ulang konfigurasi. Caching artefak linting menangani dua tantangan utama:

  • Waktu setup: menghindari instalasi ulang plugin atau environment jika tidak ada perubahan.
  • Throughput job: lint job bisa memulai lebih cepat dengan cache yang valid dan scoped per job agar tidak mengganggu job lain.

Strategi cache harus fokus pada lint config dan dependensi sensitif agar invalidasi terjadi hanya saat konfigurasi berubah.

Menentukan artefak linting yang layak dicache

Artefak linting yang paling sering dimanfaatkan adalah:

  • Config file: .eslintrc, stylelint.config.js, pyproject.toml—perubahan file ini harus memicu invalidasi.
  • Plugin/Formatter: Direktori plugin di node_modules (misalnya eslint-plugin) atau paket Python di virtualenv.
  • Cache lint lokal: file seperti .eslintcache yang menyimpan hasil lint sebelumnya.
  • Virtual environment: direktori .venv atau pipenv untuk lint berbasis Python.

Cache harus scoped per job agar lint job tetap reproducible. Gunakan key yang menggabungkan jenis runner, lint command, dan hash file konfigurasi agar cache tidak terluka bila ada perbedaan environment.

Contoh konfigurasi cache per platform

GitHub Actions: gunakan actions/cache untuk menyimpan cache lint dan dependensi.

- name: Cache lint artefak
  uses: actions/cache@v4
  with:
    path: |
      .eslintcache
      node_modules/.cache
    key: lint-${{ runner.os }}-${{ matrix.lint-tool }}-${{ hashFiles('package-lock.json', 'package.json', '.eslintrc.js') }}
    restore-keys: |
      lint-${{ runner.os }}-${{ matrix.lint-tool }}-
      lint-${{ runner.os }}-

Key di atas memastikan cache hanya dipakai oleh lint yang sama, sementara key fallback mengurangi cache miss ketika konfigurasi berubah sedikit. Matrix lint-tool bisa berupa eslint atau stylelint agar cache tidak tercampur.

GitLab CI: manfaatkan cache:key dengan files dan policy: pull-push.

lint_job:
  script:
    - npm ci
    - npm run lint
  cache:
    key:
      files:
        - package-lock.json
        - .eslintrc.js
    paths:
      - node_modules/
      - .eslintcache
    policy: pull-push
    when: on_success
    expire_in: 4 hrs

expire_in memberi TTL agar cache tidak usang. Prioritaskan files agar GitLab otomatis invalidasi saat konfigurasi berubah.

Bitbucket Pipelines: gunakan pipelines cache dengan key hash.

definitions:
  caches:
    lint-cache: |
      node_modules
      .eslintcache
pipelines:
  default:
    - step:
        caches:
          - lint-cache
        script:
          - npm ci
          - npm run lint

Untuk invalidasi, gabungkan file konfigurasi ke key custom dengan script tambahan, karena Bitbucket tidak mendukung key dinamis langsung di caches.

TTL, invalidasi, dan fallback saat cache miss

TTL (Time-to-Live) menjaga cache agar tidak menampung artefak usang. Konfigurasikan expire value di GitLab atau buat job terjadwal untuk cache warm-up di GitHub Actions. Gunakan value yang seimbang: terlalu lama membuat cache tidak sinkron dengan perubahan lint, terlalu pendek malah membuang manfaat.

Untuk invalidasi deterministik:

  • Hash file konfigurasi & package-lock.json sebagai bagian key.
  • Include versi lint tool (seperti eslint@9) di key agar perubahan major tidak menggunakan cache lama.

Fallback saat cache miss harus jelas: lint job tetap menjalankan npm ci atau pip install agar lint tetap dapat berjalan. Dokumentasikan di pipeline bahwa cache miss adalah normal bila key baru dibuat.

Validasi hasil cache linting

Untuk memastikan cache benar-benar mengurangi waktu lint:

  • Catat durasi lint job sebelum cache diaktifkan, misalnya dengan time npm run lint.
  • Setelah cache diterapkan, bandingkan waktu operasi lint pada build berikutnya dan build dengan cache miss.
  • Cek actions/cache atau GitLab cache log untuk memastikan restore berhasil.

Jika lint lebih lambat dari ekspektasi, periksa apakah key terlalu generik sehingga cache selalu invalid atau jika path tidak menyertakan file cache lint.

Catatan: cache file seperti .eslintcache harus kompatibel dengan lint versi yang digunakan. Menggunakan cache lint dari versi berbeda dapat menyebabkan False Positive/Negative.

Penanganan korupsi dan debugging

Cache artefak bisa rusak jika file cache ternary. Penanganannya:

  • Tambahkan job manual untuk membersihkan cache (misalnya actions/cache@v4 dengan upload: false lalu update key).
  • Jika lint gagal secara konsisten di cache hit, bandingkan tree file .eslintcache vs state saat linting manual.
  • Gunakan hash tambahan (misal hashFiles('lint/.eslintrc.*')) untuk memastikan plugin baru memaksa invalidasi.

Untuk troubleshooting, jalankan lint dengan verbose logging saat cache hit untuk memastikan lint tidak melewatkan file karena cache usang.

Checklist operasional cache linting

  • Pastikan file konfigurasi lint masuk ke key cache (hashFiles atau policy files).
  • Tentukan scope cache per job atau per lint tool agar tidak tercampur.
  • Set TTL/expire agar cache tidak terlalu lama.
  • Dokumentasikan fallback cache miss (instal ulang dependensi) di pipeline.
  • Pantau dampak waktu lint sebelum dan sesudah caching.
  • Jadwalkan cache refresh bila lint tool atau plugin di-upgrade.
  • Siapkan job clean up atau key baru saat cache korup.

Dengan checklist ini, cache artefak linting tetap akurat, membantu pipeline CI cepat, dan memberi feedback lint lebih cepat kepada developer.