Fix openQA Helm Chart installation

.gitea/workflows/deploy.yaml

@@ -0,0 +1,38 @@
+name: Build
+
+on:
+  push:
+    branches:
+      - master
+
+env:
+  ZOLA_VERSION: ${{ vars.ZOLA_VERSION }}
+  HOST: ${{ vars.HOST }}
+  HOST_DIR: ${{ vars.HOST_DIR }}
+  SSH_USERNAME: ${{ secrets.SSH_USERNAME }}
+  SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Install Zola
+        run: |
+          wget https://github.com/getzola/zola/releases/download/v${ZOLA_VERSION}/zola-v${ZOLA_VERSION}-x86_64-unknown-linux-gnu.tar.gz
+          tar -xvzf *.tar.gz
+
+      - name: Build
+        run: ./zola build
+
+      - name: Deploy
+        run: |
+          apt update -y && apt-get install -y --no-install-recommends rsync
+          eval "$(ssh-agent -s)"
+          ssh-add - <<< "${SSH_PRIVATE_KEY}"
+          mkdir -p ~/.ssh/
+          ssh-keyscan -H ${HOST} >> ~/.ssh/known_hosts
+          rsync -r --delete-after public/* "${SSH_USERNAME}@${HOST}:${HOST_DIR}"

content/about/index.md

@@ -12,7 +12,7 @@ It is generated to static HTML via [Zola](https://www.getzola.org/).
 
 ## Contact me
 
-- [em@0x45.cz](mailto:em@0x45.cz)
+- [em@0x45.cz](mailto:em@0x45.cz)
 - [@irungentoo](https://t.me/irungentoo) on Telegram
 - PGP: [0x453A7AE1754BFED2](https://keys.openpgp.org/vks/v1/by-fingerprint/3B08B7B5F00CCB0370EE3E71453A7AE1754BFED2)
 
@@ -36,7 +36,7 @@ Master's thesis focuses on implementing a custom ESP32 development board expanda
 
 ## Projects
 
-Some of my project are published directly at this website or in Git:
+Some of my projects are published directly at this website or in Git:
 
 - [git.0x45.cz/em](https://git.0x45.cz/em)
 - [git.microlab.space/em](https://git.microlab.space/em)

content/posts/installing-openqa-on-kubernetes-with-helm-charts/index.md

@@ -0,0 +1,127 @@
++++
+title = "Installing openQA on Kubernetes with Helm Charts"
+date = 2025-06-04
+
+[taxonomies]
+categories = ["Linux"]
+
+[extra]
+author = "Emil Miler"
++++
+
+Recently, I experimented with Kubernetes by installing [openQA](https://open.qa/) using Helm Charts. This article is a simple guide on how to do the same locally on your computer, with minimal effort.
+
+<!-- more -->
+
+You need a working cluster. There are several single-node management tools that let you run a Kubernetes cluster locally on your machine, such as [k3d](https://k3d.io/), [kind](https://kind.sigs.k8s.io/), or [minikube](https://minikube.sigs.k8s.io/). They provide a cluster entirely isolated within a container.
+
+I will be using minikube.
+
+
+## Installation of Tools
+
+Install minikube -- or any other management tool -- along with *helm*. For example, on Void Linux:
+
+```
+xbps-install -S minikube kubernetes-helm
+```
+
+You also have to have a running container engine, such as [Podman](https://podman.io/) or [Docker](https://www.docker.com/). Configuring a container engine is outside the scope of this article.
+
+
+## Preparing the Cluster
+
+
+
+Since I am using minikube, I can simply start it like so:
+
+
+```
+minikube start
+```
+
+This might take a while during the initial setup. If you want, you can also run a web-based dashboard for better visualization and debugging.
+
+```
+minikube dashboard
+```
+
+The dashboard will open in your default browser.
+
+
+## Downloading openQA Charts
+
+The official charts are available in the [openQA source code repository](https://github.com/os-autoinst/openQA), which can be cloned with the following command:
+
+
+```
+git clone https://github.com/os-autoinst/openQA.git
+```
+
+If you have GitHub setup properly with SSH, you might use this instead:
+
+```
+git clone git@github.com:os-autoinst/openQA.git
+```
+
+The charts themselves are stored in `container/helm`. You can change your working directory to that location:
+
+```
+cd openQA/container/helm
+```
+
+### Chart Structure
+
+The `charts` folder contains several different charts:
+
+- `openqa` -- Parent chart.
+- `webui` -- Web interface and API for openQA.
+- `worker` -- openQA worker that performs the actual test execution.
+
+We will be working with the parent chart `openqa`. Since it references the other charts, they will be handled automatically by the parent.
+
+
+## Installing openQA
+
+We then have to update dependencies and install openQA:
+
+```
+$ helm dependency update charts/openqa/
+$ helm install openqa charts/openqa/
+```
+
+We can also list installed releases to confirm that openQA was deployed:
+
+```
+$ helm list
+NAME  	NAMESPACE	REVISION	UPDATED                                 	STATUS  	CHART       	APP VERSION
+openqa	default  	1       	2025-06-19 12:39:08.150021755 +0200 CEST	deployed	openqa-0.1.0
+```
+
+The minikube dashboard also lists all running pods:
+
+![Minikube Dashboard, Pods](minikube-dashboard-pods.png)
+
+
+### Accessing openQA WebUI
+
+Since openQA is confined to its own network within minikube, it is not directly accessible from the host system. Below are the services running inside minikube:
+
+```
+$ kubectl get services
+NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                               AGE
+db             ClusterIP   10.103.192.20   <none>        5432/TCP                              6m34s
+db-hl          ClusterIP   None            <none>        5432/TCP                              6m34s
+kubernetes     ClusterIP   10.96.0.1       <none>        443/TCP                               174m
+openqa-webui   ClusterIP   10.104.24.71    <none>        9526/TCP,9527/TCP,9528/TCP,9529/TCP   6m34s
+```
+
+First, we need to create a proxy within the minikube network:
+
+```
+minikube tunnel
+```
+
+The openQA WebUI is running at `10.104.24.71` on port `9526` and is now accessible directly from the browser.
+
+![openQA Dashboard](openqa-dashboard.png)

content/posts/zola-deployment-with-gitea-actions-and-rsync/index.md

@@ -23,6 +23,8 @@ The Act Runner reads the private key from a secret and uses it for SSH authentic
 
 Zola is also installed by pulling a built release tar and extracting the binary. I have tried using the official Zola container, but it just would not work properly.
 
+Here is an example from this very website [deployment action](https://git.0x45.cz/em/em.0x45.cz/src/branch/master/.gitea/workflows/deploy.yaml):
+
 ```yaml
 name: Build
 
@@ -32,9 +34,9 @@ on:
       - master
 
 env:
-  ZOLA_VERSION: "0.18.0"
-  HOST: ${{ secrets.SSH_HOSTNAME }}
-  HOST_DIR: ${{ secrets.SSH_TARGET_DIR }}
+  ZOLA_VERSION: ${{ vars.ZOLA_VERSION }}
+  HOST: ${{ vars.HOST }}
+  HOST_DIR: ${{ vars.HOST_DIR }}
   SSH_USERNAME: ${{ secrets.SSH_USERNAME }}
   SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
 
@@ -64,6 +66,8 @@ jobs:
           rsync -r --delete-after public/* "${SSH_USERNAME}@${HOST}:${HOST_DIR}"
 ```
 
+The example cinfiguration uses both secrets and vars from within Gitea. These have to be set trough the web UI under *Settings > Actions*.
+
 ## Webserver configuration
 
 The server needs a new user with write access to the website root directory. I still call it drone for the sake of not having to redo my server configuration.
@@ -88,7 +92,13 @@ Public key has to be added to `~/.ssh/authorized_keys` of the "drone" user.
 
 |                   |                        |
 |-------------------|------------------------|
-| `SSH_HOSTNAME`    | Server hostname        |
-| `SSH_TARGET_DIR`  | Website root directory |
 | `SSH_USERNAME`    | In our case "drone"    |
 | `SSH_PRIVATE_KEY` | Plaintext private key  |
+
+## Vars
+
+|                   |                        |
+|-------------------|------------------------|
+| `ZOLA_VERSION`    | Version of Zola        |
+| `HOST`            | Server hostname        |
+| `TARGET_DIR`      | Website root directory |