finish hugo migration article

content/posts/migrate-from-ghost-to-hugo/index.md

@@ -38,17 +38,36 @@ It's a highly flexible and customizable theme, regularly updated, with a minimal
 
 ## Migration
 ### Settings
+To set up hugo and the theme, I used the [Blowfish documentation](https://blowfish.page/docs/). Many elements are detailed and give a good start.
+
+I've chosen to structure my blog in 2 parts: articles and projects. This will enable me to quickly and easily create pages dedicated to my personal projects, while remaining separate from the rest of the blog's publications.
 
 
 ### Contents and optimization
 
+For the moment I've only migrated the posts from my old blog and not the CTF writeups. I haven't found a good solution for transforming Ghost posts into a format that Hugo can use autonomously. I'll try to make a script that will do it in an optimized way and with support for image migration.
+
+Once the articles had been manually migrated, I looked into support for web-optimized image formats such as webp and avif. It turns out that hugo supports it, but doesn't take into account the compatibility option for older browsers. After a bit of research, I found the following article that answered my problem:
+
+[WebP and AVIF images on a Hugo website](https://pawelgrzybek.com/webp-and-avif-images-on-a-hugo-website/)
+
+To create this solution, I first need to generate a webp version of my png images. To do this, I use the following command:
+
 ```bash
 find ./content/ -type f -name '*.png' -exec sh -c 'cwebp -q 90 $1 -o "${1%.png}.webp"' _ {} \;
 ```
-https://pawelgrzybek.com/webp-and-avif-images-on-a-hugo-website/
+
+I can then create the file `layouts/_default/_markup/render_images.html` with the code shown in the article. And then, all that's left is to integrate the images into my articles using the following tag:
+
+```
+![TEXT](img/image-X.webp)
+```
 
 ## Storage and automatic deployment
 ### Git-LFS
+My blog is now file-based, so I'm going to store it in a git project (more precisely on my Gitea intance). There's a problem: it's made up of a lot of images, which aren't really the type of file to put in a git project. To solve this problem, I'm going to use git LFS (Large File Storage) feature.
+
+To do so, I first install `git-lfs` and add it to the project, then set the file extensions I want to put in LFS:
 
 ```bash
 apt install git-lfs
@@ -59,10 +78,15 @@ git lfs migrate \
         --include-ref=refs/heads/main
 ```
 
+And that's all there is to it! You just need to make sure that LFS is also enabled on Gitea, which it is. The next time you push, files with include extensions should be in LFS.
+
 ### CI/CD
+Last step of the migration, I'm going to make an automatic deployment of my blog when I push a new article. To do this, I'll use CI/CD.
+
+At first I used a CI that generated an image with the version of hugo I wanted, then generated my blog and finally added it to a nginx image. But after a few tests I realized that creating an image with hugo took up to 5min on my worker. So I'm going to create 2 workflows; one for creating the Hugo image and the second for building my blog. In fact, I only need a new hugo when I bump its version.
 
 #### Hugo docker image
-hugo.Dockerfile:
+Start with the Hugo image with its Dockerfile and associated workflow:
 ```dockerfile
 FROM golang:1.22-alpine AS build
 
@@ -76,8 +100,6 @@ RUN apk update && \
 RUN go install -tags extended github.com/gohugoio/hugo@v0.123.3
 ```
 
-
-
 ```yml
 name: Build Hugo Docker Image
 
@@ -110,11 +132,11 @@ jobs:
           platforms: linux/amd64
           push: true
           tags: git.d3vyce.fr/d3vyce/hugo:latest
-
 ```
+This workflow will only be triggered if I make a modification to the `hugo.Dockerfile` (for example, if I bump hugo's version).
 
 #### Blog docker image
-Dockerfile:
+I can then use this image in every build of my blog with the following Dockerfile:
 ```dockerfile
 # Build Stage
 FROM git.d3vyce.fr/d3vyce/hugo:latest AS build
@@ -135,6 +157,7 @@ COPY nginx/ /etc/nginx/
 
 EXPOSE 80/tcp
 ```
+As you can see, to avoid basing myself on the submodule's upstream, I'm going one checkout further to base myself on a tag.
 
 ```yaml
 name: Build Blog Docker Image
@@ -178,13 +201,15 @@ jobs:
           push: true
           tags: git.d3vyce.fr/${{ github.repository }}:latest
 ```
-
+This workflow will be executed for each commit to master. As you can see, I didn't use the LFS option of `actions/checkout@v3`. This is due to a bug with Gitea:
 https://gitea.com/gitea/act_runner/issues/164
 
-## Conclusion: before/after comparison
-Après avoir terminé la migration, j'ai comparé les 2 solutions.
+To fix this bug I had to add a `Checkout LFS` step as recommended in the issue.
+
+## Conclusion: before/after comparison
+
+After completing the migration, I compared the 2 solutions.
 
-### Performance
 Lighthouse result for Ghost based blog:
 ![Ghost based blog lighthouse result](img/image-2.webp)
 
@@ -199,5 +224,6 @@ Lighthouse result for Hugo based blog:
 | Cumulative Layout Shift  | 0.001        | 0               |
 | Speed Index              | 0.6 s        | 0.3 s           |
 
-### Ressources
+We can see that Hugo is faster in all the aspects tested by lighthouse than Ghost. In terms of resources, Hugo consumes much less, using around 10/15MB of RAM compared with Ghost, which consumes over 230/250MB of RAM (not counting the mysql that Ghost uses to run).
 
+In conclusion, I'm not disappointed that I took the time to migrate my blog to Hugo. It took time, but it will pay off in time for the ease of updating, customization, ...