Pengalaman Migrasi Blog dari Jekyll ke Hugo yang Tidak Sempurna
Sebagian besar posting blog saya adalah pelajaran yang dipelajari. saya mencoba untuk mencapai sesuatu, dan saya mendokumentasikan proses yang saya gunakan untuk melakukannya. ini adalah salah satu dari beberapa di mana, pada akhirnya, saya tidak mencapai apa yang saya inginkan. dalam posting ini, saya bertujuan untuk menjelaskan apa yang saya pelajari dari mencoba bermigrasi dari Jekyll ke Hugo, dan mengapa, pada akhirnya, saya tidak mengambil langkah terakhir.
konteksnya
Saya memulai blog ini di WordPress. Setelah beberapa tahun, saya memutuskan untuk Migrasi ke Jekyll Saya sudah senang dengan Jekyll Ini didasarkan pada Ruby, dan meskipun saya bukan pengembang Ruby, saya dapat membuat beberapa plugin.
Saya menyimpan basis kode di GitLab, dengan GitLab CI, dan saya telah mengkonfigurasi Renovate untuk membuat PR ketika sebuah perhiasan sudah usang. Dengan cara ini, saya membayar hutang teknis setiap kali, dan saya tidak menggunakannya selama bertahun-tahun. pekan lalu, saya mendapat PR untuk memperbarui gambar Ruby Docker ibu dari 3.4 Dua 4.0.
Saya memeriksa apakah Jekyll siap untuk Ruby 4. Masalah terbuka Namun, itu tidak hanya Jekyll: Gemfile menggunakan permata yang versi tidak kompatibel dengan Ruby 4.
Lebih parah lagi, saya memeriksa kesehatan umum dari Proyek Jekyll Komitmen terakhir adalah beberapa minggu yang lalu dari bot Kontinuous Integration. saya pikir mungkin sudah waktunya untuk mencari alternatif.
Hugo yang
Sama seperti Jekyll, Hugo yang Ini adalah generator situs statis.
Hugo adalah salah satu generator situs statis open source yang paling populer.Dengan kecepatan dan fleksibilitasnya yang menakjubkan, Hugo membuat membangun situs web menyenangkan lagi.
Hugo adalah salah satu generator situs statis open source yang paling populer.Dengan kecepatan dan fleksibilitasnya yang menakjubkan, Hugo membuat membangun situs web menyenangkan lagi.
Berbeda dengan Jekyll, Hugo membangun pada Go. Ia memuji dirinya sebagai "sangat cepat". Kodifikasi Meskipun saya bukan penggemar Go, saya memutuskan Hugo adalah target migrasi yang baik.
Jekyll untuk Hugo
Migrasi dari Jekyll ke Hugo mengikuti hukum Pareto.
Migrasi Konten
Hugo menyediakan folder utama berikut:
Jekyll membedakan antara Postingan dan halaman Yang pertama memiliki tanggal, yang terakhir tidak. Jadi, posting adalah dasar dari sebuah blog. Halaman stabil dan struktur situs. Hugo tidak membuat perbedaan ini.
Jekyll folder struktur peta sebagai:
_posts
content/posts
_pages/
content/posts/
_data
data
_layouts
layouts
assets
static
Ketika Mapping Tidak Cukup
Jekyll menawarkan Plugin yang Plugin datang dalam beberapa kategori:
Generators - Create additional content on your site
Converters - Change a markup language into another format
Commands - Extend the jekyll executable with subcommands
Tags - Create custom Liquid tags
Filters - Create custom Liquid filters
Hooks - Fine-grained control to extend the build process
Generator - Membuat konten tambahan di situs Anda
Konverter - Mengubah bahasa markup ke format lain
Commands - Extend the jekyll executable dengan subcommand
Tags - Membuat Custom Liquid Tags
Filter - Membuat filter cair yang disesuaikan
Hooks - kontrol biji halus untuk memperpanjang proses konstruksi
Pada Jekyll, saya menggunakan generator, tag, filter, dan hooks. Plugin Twitter; yang lain dikembangkan khusus untuk kebutuhan saya sendiri.
Jekyll tags terjemahan untuk Pendekatan Untuk Hugo :
Shortcode adalah template yang dipanggil dalam markup, menerima sejumlah argumen apa pun. Mereka dapat digunakan dengan format konten apa pun untuk memasukkan elemen seperti video, gambar, dan media sosial tertanam ke dalam konten Anda.
Ada tiga jenis shortcode: embedded, custom, dan inline.
Shortcode adalah a Kuilnya yang ditandatangani dalam rangka menandatangani sejumlah Argumen Mereka dapat digunakan dengan format konten apa pun untuk memasukkan elemen seperti video, gambar, dan media sosial tertanam ke dalam konten Anda.
Ada tiga jenis shortcode: embedded, custom, dan inline.
Hugo menawarkan cukup banyak koleksi shortcodes out-of-the-box, tetapi Anda dapat meluncurkan sendiri.
Sayangnya, generator tidak memiliki setara di Hugo. saya telah mengembangkan generator untuk membuat newsletter dan halaman percakapan. plugin generator secara otomatis menghasilkan satu halaman per tahun menurut data saya. di Hugo, saya harus secara manual membuat satu halaman per tahun.
Menggunakan GitLab Build
Konstruksi Jekyll terdiri dari tiga langkah:
Mendeteksi jika salah satu dari Gemfile.lock, Dockerfile, atau .gitlab-ci.yml telah berubah, dan membangun gambar Docker jika demikian
Menggunakan gambar Docker untuk benar-benar membangun situs
Menggunakan GitLab Pages
Perubahan yang paling penting terjadi pada Dockerfile Berikut adalah versi baru Hugo untuk referensi:
FROM docker.io/hugomods/hugo:exts ENV JAVA_HOME=/usr/lib/jvm/java-21-openjdk ENV PATH=$JAVA_HOME/bin:$PATH WORKDIR /builds/nfrankel/nfrankel.gitlab.io RUN apk add --no-cache openjdk21-jre graphviz \ #1 && gem install --no-document asciidoctor-diagram asciidoctor-diagram-plantuml rouge #2
Paket untuk Plantuml
Perhiasan untuk diagram Asciidoctor dan sintax highlighting
Pada saat ini, saya harus mencium bau ikan, tapi itu berhasil, jadi saya melanjutkan.
Kesepakatan Breaker
Saya bermigrasi dengan bantuan Claude Code dan Copilot CLI. Saya membutuhkan beberapa sesi, tersebar selama seminggu, sebagian besar pada malam hari dan akhir pekan. Selama migrasi, saya secara teratur meminta perbandingan satu-ke-satu untuk menghindari regresi. Ide saya adalah untuk membangun situs Jekyll dan Hugo bersebelahan, mendistribusikannya keduanya di GitLab Pages, dan membandingkan kedua versi yang didistribusikan untuk kesenjangan akhir.
Saya memperbarui build untuk melakukan itu, dan saya memicu build: build Jekyll mengambil sedikit lebih dari dua menit, sementara build Hugo mengambil lebih dari sepuluh!
Saya menganalisis log untuk lebih memahami masalah. selain beberapa peringatan, saya tidak melihat apa-apa yang menjelaskan dari mana perlambatan itu berasal.
│ EN ──────────────────┼────── Pages │ 2838 Paginator pages │ 253 Non-page files │ 5 Static files │ 2817 Processed images │ 0 Aliases │ 105 Cleaned │ 0 Total in 562962 ms
Ketika saya bertanya kepada Claude Code, itu menunjukkan penggunaan Asciidoc saya dalam posting saya. sementara Hugo sangat mendukung Asciidoc (dan Format lainnya), ia menyerahkan format selain Markdown ke mesin eksternal. untuk Asciidoc, itu asciidoctor Ternyata pendekatan ini bekerja dengan baik untuk beberapa dokumen Asciidoc, tidak begitu banyak untuk lebih dari 800. Thread ini Spanyol lima tahun.
Mengatakan bahwa saya kecewa adalah pengecualian. saya meninggalkan pekerjaan di cabang. saya mungkin akan menghapusnya di masa depan, setelah saya mendinginkan.
Kesimpulan
Sebelum bekerja pada migrasi, saya melakukan kewajiban saya dan mengklaim kelayakan teknis dari pekerjaan. Saya melakukannya dengan membaca dokumentasi dan chatting dengan LLM. Namun, saya membuang-buang waktu untuk melakukan pekerjaan sebelum meluncur kembali. Saya agak marah terhadap dokumentasi Hugo karena tidak menyebutkan perilaku dan kinerja yang dicetak dengan huruf merah berani.
Menggunakan Java Geek




