Gitea 28.3.0: Indeks Baru dan Dasbor Issue Lebih Cepat

Gitea 28.3.0 terbit 1 November 2026 dengan tiga peningkatan, lima perbaikan performa, dan puluhan perbaikan bug menurut catatan rilis resminya. Sorotan utamanya ada di sisi basis data: sebuah indeks yang hilang membuat SQLite membaca hampir setiap baris tabel job pada fitur Actions, dan masalah itu ditutup di versi ini. Bagi tim yang menjalankan Gitea sendiri, rilis ini lebih layak dipasang karena perbaikan operasional daripada karena fitur baru.

TL;DR

• Gitea 28.3.0 keluar 1 November 2026, berisi 3 peningkatan, 5 perbaikan performa, dan banyak perbaikan bug.
• Indeks is_reusable_caller ditambahkan karena query lama membaca hampir seluruh baris tabel job di SQLite.
• Dasbor issue dan pull request dipercepat, termasuk perbaikan indeks tabelnya.
• Beberapa perbaikan menyentuh hak akses, misalnya feed tag tidak lagi membocorkan catatan rilis.
• Upgrade rutin: ambil biner baru, jalankan migrasi otomatis, lalu verifikasi versi di halaman admin.

Kenapa rilis ini penting untuk instalasi Gitea berskala kecil?

Karena masalah paling mahal di instalasi kecil biasanya bukan fitur yang kurang, melainkan query yang tidak efisien. Catatan rilis menyebut satu perbaikan secara eksplisit: indeks untuk is_reusable_caller dibuat karena tanpa indeks tersebut SQLite nyaris membaca setiap baris tabel job. Pada server dengan RAM terbatas, pola query seperti itu adalah penyebab utama halaman yang lambat dan disk yang terus bekerja.

Perbaikan indeks itu masuk lewat pull request 40064. Bagi pengguna PostgreSQL atau MySQL, dampaknya mungkin tidak sebesar SQLite, tetapi perbaikan indeks tetap relevan karena perencana query juga bergantung pada statistik dan struktur indeks. Yang perlu dicatat, perbaikan semacam ini tidak memerlukan perubahan konfigurasi dari sisi admin. Migrasi dijalankan otomatis saat biner baru start.

Ada juga percepatan pada dasbor issue dan pull request, termasuk perbaikan indeks tabel, percepatan daftar issue dan pull request per repositori, serta pengurangan pekerjaan saat memuat status commit. Ketiga hal itu adalah halaman yang paling sering dibuka di instalasi dengan banyak repositori, jadi efeknya terasa langsung pada pengalaman sehari-hari, terutama di repositori dengan riwayat panjang.

Perbaikan apa yang menyentuh hak akses dan keamanan?

Beberapa butir di bagian bug fixes berkaitan dengan batas akses, dan itu yang membuat rilis ini layak diprioritaskan. Contohnya, cakupan token publik kini ditegakkan di lebih banyak rute, feed tag tidak lagi menampilkan catatan rilis bagi pengguna tanpa hak akses rilis, dan endpoint sub-sumber daya issue memeriksa izin baca unit sebelum menjawab permintaan.

Di sisi Actions, ada dua perbaikan yang relevan untuk operator: batas penyimpanan artefak yang diminta kini dibatasi, dan header Content-Encoding yang tidak tepercaya dibuang dari unggahan artefak versi 1. Keduanya menutup jalur di mana permintaan yang dibuat pengguna bisa memaksa server menyimpan lebih banyak data daripada yang seharusnya, atau memproses header yang tidak berasal dari server sendiri.

Area	Perubahan di 28.3.0	Arti untuk operator
Basis data	Indeks is_reusable_caller, perbaikan indeks dasbor	Query job dan halaman daftar lebih ringan
Token dan izin	Cakupan token publik ditegakkan di lebih banyak rute	Token terbatas tidak bisa dipakai di luar cakupannya
Feed dan rilis	Catatan rilis disembunyikan tanpa hak akses	Kebocoran informasi lewat feed tertutup
Actions	Batas retensi artefak, header encoding tidak tepercaya dibuang	Unggahan artefak lebih terkendali
Migrasi	Migrasi GitHub memakai paginasi kursor	Impor issue besar lebih stabil

Yang tidak ada di rilis ini sama pentingnya untuk dicatat: tidak ada perubahan konfigurasi wajib dan tidak ada perubahan format basis data yang menuntut langkah manual di luar migrasi otomatis. Kalau tim Anda punya kebijakan menunggu satu versi patch sebelum upgrade, 28.3.0 adalah titik yang wajar untuk dipasang karena 28.2.0 sudah berjalan sejak 18 Oktober 2026.

Bagaimana urutan upgrade yang aman untuk Gitea 28.3.0?

Cadangkan dulu, lalu ganti biner, lalu biarkan migrasi berjalan, dan verifikasi di akhir. Urutan itu terdengar klise, tetapi pada Gitea langkah cadangan punya bentuk konkret: salin berkas konfigurasi, direktori data, dan basis data dalam keadaan berhenti atau konsisten. Jangan menyalin berkas SQLite saat layanan sedang menulis, karena hasilnya bisa berupa salinan yang rusak.

Setelah cadangan ada, ganti biner dan jalankan layanan. Migrasi dijalankan otomatis pada start pertama, dan untuk instalasi besar langkah ini bisa memakan waktu. Jangan menghentikan proses di tengah migrasi hanya karena halaman belum bisa diakses. Tunggu sampai log menunjukkan proses selesai, lalu periksa halaman admin untuk memastikan versi yang tampil sudah 28.3.0.

Verifikasi berikutnya bersifat fungsional: buka dasbor issue, buka satu pull request dengan banyak commit, dan buka satu job Actions. Ketiganya adalah area yang berubah di rilis ini, jadi kalau ada masalah, gejalanya akan muncul di sana lebih dulu. Periksa juga log server untuk pesan error migrasi dan pastikan tidak ada indeks yang gagal dibuat.

Untuk instalasi yang memakai SQLite, perhatikan ukuran berkas dan waktu respons setelah upgrade. Perbaikan indeks seharusnya menurunkan waktu query pada tabel job, tetapi efeknya baru terasa setelah halaman diakses beberapa kali. Kalau waktu respons masih buruk, periksa apakah ada job Actions lama yang menumpuk, karena data yang besar tetap mahal dipindai meski indeksnya sudah benar.

Apa yang berubah pada Actions dan webhook?

Di sisi webhook, notifikasi sekarang menyebut aset rilis, bukan hanya nama rilisnya. Perubahan ini kecil di permukaan tetapi berguna untuk otomasi: penerima webhook bisa langsung tahu aset mana yang menyertai sebuah rilis tanpa harus memanggil API tambahan. Kalau pipeline Anda memakai webhook untuk memicu deploy berdasarkan nama aset, periksa format payload-nya setelah upgrade, karena penambahan medan bisa memengaruhi parser yang ketat.

Di sisi Actions, dua perbaikan menyentuh verifikasi dan penyimpanan. Verifikasi token runner yang berhasil kini di-cache, yang berarti pengurangan pekerjaan berulang pada setiap job. Sementara itu, batas retensi artefak kini dibatasi sesuai permintaan, sehingga permintaan yang meminta masa simpan sangat panjang tidak lagi diterima begitu saja.

Perbaikan lainnya menyentuh pengurutan dan tampilan data: query untuk daftar issue dan pull request dipercepat, dan pemuatan status commit tidak lagi memuat repositori berulang kali untuk setiap status. Pada repositori dengan banyak commit dan banyak pemeriksaan, pola seperti itu merupakan sumber waktu tunggu yang tidak terlihat di UI tetapi terasa di setiap kali halaman dibuka.

Untuk migrasi, ada dua perbaikan yang relevan bagi tim yang pindah dari GitHub atau OneDev. Migrasi issue GitHub kini memakai paginasi kursor, dan migrasi dari OneDev 16.8 ke atas diperbaiki. Kalau Anda sedang dalam proses pindah dan sempat gagal di tengah jalan, versi ini adalah alasan yang baik untuk mencoba ulang sebelum menyimpulkan bahwa datanya tidak kompatibel.

Peningkatan kecil yang layak diketahui

Tiga butir di bagian enhancements tidak mengubah cara kerja, tetapi menyentuh hal yang dilihat pengguna setiap hari. Yang pertama adalah perbaikan tampilan hover pada grup tombol berwarna, yang membuat batas tombol lebih jelas saat kursor berada di atasnya. Perbaikan antarmuka seperti ini sulit diukur dampaknya, tetapi mengurangi salah klik pada antarmuka yang padat.

Yang kedua menyentuh fitur proyek: milestone sekarang bisa difilter berdasarkan issue yang tertaut. Bagi tim yang memakai milestone untuk merencanakan rilis, filter ini mengurangi pekerjaan manual saat menyusun daftar pekerjaan yang benar-benar masuk ke sebuah milestone, dan itu relevan di repositori yang issue-nya banyak tetapi tidak semuanya ditautkan.

Yang ketiga adalah notifikasi webhook untuk aset rilis yang sudah dibahas sebelumnya. Ketiganya masuk kategori peningkatan, bukan perbaikan, yang berarti perilaku lama tetap berjalan. Kalau tim Anda punya dokumentasi internal soal alur kerja proyek, tambahkan catatan soal filter milestone agar orang lain tahu fitur itu ada.

Checklist pasca-upgrade

• Pastikan halaman admin menampilkan versi 28.3.0 dan tidak ada migrasi yang gagal.
• Buka dasbor issue dan pull request pada repositori terbesar, bandingkan waktu muat.
• Periksa satu job Actions dan pastikan artefaknya masih bisa diunduh.
• Uji feed tag pada repositori privat untuk memastikan catatan rilis tidak muncul bagi pengguna tanpa hak akses.
• Periksa payload webhook rilis kalau ada otomasi yang membacanya.
• Simpan berkas cadangan konfigurasi dan basis data sampai satu siklus operasi berjalan normal.

Untuk tim yang mengelola lebih dari satu instance, jalankan satu instance lebih dulu dan tunggu setidaknya satu hari kerja sebelum menaikkan sisanya. Rilis patch seperti ini jarang bermasalah, tetapi perbedaan konfigurasi antar instance, misalnya satu memakai SQLite dan yang lain PostgreSQL, membuat hasil pengujian di satu instance tidak otomatis berlaku di instance lain.

Satu hal lagi yang sering terlewat: periksa ruang disk sebelum upgrade. Migrasi indeks dan pembersihan data bisa membutuhkan ruang sementara, dan pada server kecil ruang yang menipis adalah penyebab kegagalan migrasi yang paling mudah dihindari. Kalau ruang tersisa tipis, bersihkan artefak Actions lama lebih dulu lewat pengaturan retensi.

Catatan untuk instalasi dengan banyak pengguna

Pada instance yang dipakai banyak tim, perbaikan hak akses adalah alasan terkuat untuk tidak menunda. Pemeriksaan izin pada endpoint sub-sumber daya issue dan penegakan cakupan token publik mengurangi kemungkinan satu tim melihat data tim lain lewat jalur yang seharusnya tertutup. Setelah upgrade, tinjau juga token yang masih aktif dan cabut yang tidak lagi dipakai, karena pengetatan di sisi server tidak menggantikan kebersihan daftar token.

FAQ

Apakah Gitea 28.3.0 memerlukan perubahan konfigurasi?

Tidak. Rilis ini berisi perbaikan dan peningkatan tanpa opsi konfigurasi wajib baru. Migrasi basis data berjalan otomatis pada start pertama setelah biner diganti.

Apakah aman melompat langsung dari 28.1.0 ke 28.3.0?

Umumnya aman karena migrasi Gitea berjalan berurutan, tetapi tetap cadangkan basis data lebih dulu. Kalau instalasi Anda melewati beberapa versi minor, baca catatan rilis tiap versi yang dilewati untuk memastikan tidak ada langkah manual.

Kenapa saya tidak merasakan percepatan setelah upgrade?

Perbaikan indeks paling terasa pada tabel job yang besar. Kalau instalasi Anda masih kecil atau jarang memakai Actions, selisih waktunya memang sulit dirasakan. Periksa juga apakah halaman yang diuji benar-benar memakai jalur query yang diperbaiki.

Di mana catatan rilis lengkapnya?

Ada di halaman rilis v28.3.0 dengan tautan tiap pull request. Panduan upgrade tersedia di dokumentasi Gitea, dan pengaturan umum ada di docs.gitea.com.

Rekomendasi Tools & Layanan

Beberapa layanan yang dipake di panduan ini: free trial Alibaba Cloud (coba gratis, sesuaikan kebutuhan), dan halaman promo terbaru buat cek diskon yang lagi jalan bulan ini.