Move all pictures to LFS

content/posts/argocd-dynamic-environment-per-branch-part-1/index.md

@@ -4,7 +4,7 @@ date: 2023-02-25T14:00:00+01:00
 draft: false
 ShowToc: true
 cover:
-    image: "cover.png"
+    image: "/posts/argocd-dynamic-environment-per-branch-part-1/cover.png"
     caption: "Dynamic Environment Per Branch with ArgoCD"
     relative: false
     responsiveImages: false
@@ -98,7 +98,7 @@ containers:
         name: nginx-config
 ```
 
-So in the `init` container I'm generating a static content (`--baseUrL` flag is templated with `Helm`). Putting the result to the directory that is mounted as en `emptyDir` volume. And then later I'm mounting this folder to a container with `nginx`. Now I can use my docker image wherever I'd like with the same result It doesn't depend on the hostmame that was fixed during the build.
+So in the `init` container I'm generating a static content (`--baseUrL` flag is templated with `Helm`). Putting the result to the directory that is mounted as en `emptyDir` volume. And then later I'm mounting this folder to a container with `nginx`. Now I can use my docker image wherever I'd like with the same result It doesn't depend on the hostname that was fixed during the build.
 
 ### No more `latest`
 Since I want to have my envs updated on each commit, I can't push only `latest` anymore. So I've decided to use `commit sha` as tags for my images. But it means that I'll have a lot of them now and having `300Mb` of images and other media is becoming very painful. That means that I need to stop putting images directly to container during the build. So instead of using `rclone` to get data from `minio` in a `drone` pipeline, I'm adding another `init` container to my deployment.   
@@ -481,7 +481,7 @@ foreach my $line (@builds_out)
 ```
 {{< /details >}}
 
-It's far from being perfect, but it works and I like that I was able to finally use `Perl` somewhere
+It's far from being perfect, but it works, and I like that I was able to finally use `Perl` somewhere
 
 2. I want to have a manifest that I can apply in case of kind of *disaster recovery*. And it means that `ApplicationSet` should contain enough information to deploy a production instance of my blog right off the bat. But I don't want to keep it up-to-date with every new commit hash. So I've decided to keep pushing `latest` to registry but only on `main` builds. So I can use the latest tag in application set, but in the application life-time I'll keep using `SHA` as tags. The only static hard-coded value in the `ApplicationSet` is a version of the `Helm chart`. And I don't know how to automate it yet. But I'm sure that I will do it somehow. 
 I know that it's a very common practice to store all `Argo` resource in `git`. But I don't see any sense in storing manifests for temporary environments that can be recreated by clicking a button in `Drone` or by pushing a new commit.

content/posts/argocd-vs-helmfile-application/index.md

@@ -3,7 +3,7 @@ title: "ArgoCD vs Helmfile: Applications"
 date: 2023-02-13T12:14:09+01:00
 draft: false
 cover:
-    image: "cover.png"
+    image: "/posts/argocd-vs-helmfile/cover-applications.png"
     caption: "ArgoCD"
     relative: false
     responsiveImages: false

content/posts/argocd-vs-helmfile-applicationset/index.md

@@ -3,7 +3,7 @@ title: "ArgoCD vs Helmfile: ApplicationSet"
 date: 2023-02-15T10:14:09+01:00
 draft: false
 cover:
-    image: "cover.png"
+    image: "/posts/argocd-vs-helmfile/cover-applicationset.png"
     caption: "ArgoCD"
     relative: false
     responsiveImages: false

content/posts/dont-use-argocd-for-infrastructure/index.md

@@ -4,7 +4,7 @@ date: 2023-02-09T12:47:32+01:00
 draft: false
 ShowToc: true
 cover:
-    image: "cover.png"
+    image: "/posts/dont-use-argocd-for-infrastructure/cover.png"
     caption: "ArgoCD"
     relative: false
     responsiveImages: false

content/posts/vst-on-linux-1/index.md

@@ -4,7 +4,7 @@ date: 2023-01-24T15:47:50+01:00
 draft: false
 ShowToc: true
 cover:
-    image: "cover.png"
+    image: "/posts/vst-on-linux-1/cover.png"
     caption: "Vst on Linux"
     relative: false
     responsiveImages: false
@@ -97,7 +97,7 @@ Why we're adding this `WINEPREFIX` thing every time when running `wine`? Because
 
 After installing this plugin, I will need to add it to **yabridge**. To do that, use **yabridgectl**
 
-Insted of what I'm putting after `/drive_c/`, provide a path that you've chosen during the installation
+Instead of what I'm putting after `/drive_c/`, provide a path that you've chosen during the installation
 
     $ yabridgectl add ~/.wine_vst_plugins/drive_c/Program\ Files/Common\ Files/VST
     $ yabridgectl sync 

content/posts/vst-on-linux-2/index.md

@@ -3,7 +3,7 @@ title: "Vst on Linux 2"
 date: 2023-01-31T19:32:34+01:00
 ShowToc: true
 cover:
-    image: "cover.png"
+    image: "/posts/vst-on-linux-2/cover.png"
     caption: "VST on Linux"
     relative: false
     responsiveImages: false

content/posts/vst-on-linux-3/index.md

@@ -4,7 +4,7 @@ date: 2023-02-03T18:26:44+01:00
 draft: false
 ShowToc: true
 cover:
-    image: "cover.png"
+    image: "/posts/vst-on-linux-1/cover.png"
     caption: "Vst on Linux"
     relative: false
     responsiveImages: false