1st published item
All checks were successful
Publish new notes / build-quartz (push) Successful in 2m0s
Publish new notes / deploy (push) Successful in 28s

This commit is contained in:
VR 2025-06-22 23:09:03 +01:00
parent e3b8ba7140
commit adbce7ceb6
4 changed files with 74 additions and 6 deletions

View File

@ -1,5 +1,5 @@
name: Gitea Actions Demo
run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀
name: Publish new notes
run-name: Build in Quartz and push to Nginx
on: [push]
jobs:

View File

@ -170,6 +170,7 @@
},
"active": "a7a84c356653d530",
"lastOpenFiles": [
"Pasted image 20250622224303.png",
"notes/index.md",
"here.md",
"notes/0000-how-this-was-built.md"

Binary file not shown.

After

Width:  |  Height:  |  Size: 166 KiB

View File

@ -5,7 +5,7 @@ tags:
- cicd
- quartz
- github-actions
draft: true
draft: false
---
### Why?
@ -25,7 +25,7 @@ Summarised, I had to:
- [ ] Create a notes repo and the Github Actions workflow for auto deployment
- [ ] Troubleshoot the whole things until it works (always the fun bit)
##### Nginx pod setup
##### Nginx pod
Nothing fancy, manifests below and explanations after.
@ -211,6 +211,73 @@ spec:
I needed the PVC to persists the data if the pod or the node crashes - it's hosted on an SSD attached to an NFS server that is exposed via a StorageClass to the cluster. The certificate is managed via [CertManager](https://cert-manager.io/) and is issued by Let'sEncrypt - always good to use TLS! The service simply ties the pod to the ingress, not much to say here. The ingress uses the Nginx admission controller and is configured with the Let'sEncrypt cert to enable TLS. The config map has a minimal Nginx config file that is mounted to the pod under "/etc/nginx/nginx.conf". Lastly, the deployment which ties it all together - not much to say, it's just one Nginx replica. Good practice says that I should add some resource limits and requests, but I'll leave that for later with the rest of the tech debt...
#### Notes repo and Github Actions workflow setup
#### Notes repo and Github Actions workflow
TBC
Nothing special here - I'm running a local Gitea instance, so I just created a new [repo](https://k3gtpi.jumpingcrab.com/vlad/vlads-notes) there and saved the K8s cluster config as a repo secret called "K8S_CONF" (use secrets instead of plain variables as the latter can be exposed in the action's logs)
![[Pasted image 20250622224303.png]]
I then created the ".gitea/workflows" directories and placed the workflow YAML file (publish.yaml) within. The workflow is split into two jobs:
- 1st job
- checks out the files from the repo
- clones Quartz (from a repo clone hosted locally) to the working directory
- copies notes from "./notes" directory to the "./quartz-clone" and triggers the Quartz build
- uploads the files created by Quartz as artifacts for the next job
- 2nd job
- copies these artifacts locally
- installs the kubectl client
- copies the K8s config from the secret into the required path
- gets the Nginx's pod name
- deletes old files from the Nginx root directory and copies the new files built by Quartz
Contents:
```
name: Publish new notes
run-name: Build in Quartz and push to Nginx
on: [push]
jobs:
build-quartz:
runs-on: ubuntu-latest
container:
image: node:24.2
steps:
- name: Grab local files
uses: actions/checkout@v4
- name: Clone local copy of Quartz
run: git clone https://k3gtpi.jumpingcrab.com/vlad/quartz-clone.git
- name: Copy notes to content directory
run: cp ./notes/* quartz-clone/content
- name: Build Quartz
run: cd quartz-clone && npm i && npx quartz create && npx quartz build
- name: Upload artifact
uses: actions/upload-artifact@v3
with:
name: content
path: quartz-clone/public
deploy:
runs-on: ubuntu-latest
needs: build-quartz
steps:
- name: Get artifacts
uses: actions/download-artifact@v3
with:
name: content
path: ./content
- name: Install kubectl
run: curl -LO https://dl.k8s.io/release/v1.33.0/bin/linux/arm64/kubectl && chmod +x kubectl && mv kubectl /usr/bin
- name: Set up cluster access
run: mkdir ~/.kube && echo "${{ secrets.K8S_CONF }}" > ~/.kube/config
- name: Get target pods's name
run: echo "TARGET_POD=$(kubectl get pods -n my-stuff -l app=digital-garden -o json | jq -r .items[0].metadata.name)" >> "$GITHUB_ENV"
- name: Copy contents to pod temp folder (due to permission issues)
run: kubectl cp content my-stuff/$TARGET_POD:/tmp
- name: Change permissions and move files to WWW directory
run: kubectl exec -i -n my-stuff $TARGET_POD -- bash -c "chown -R 1000:1000 /tmp/content && rm -rf /www/data/* && mv /tmp/content/* /www/data"
```
#### Troubleshooting
Compared to Gitlab CI, I think Actions is simpler to use but it has it's quirks - the main difficulty I found was around sharing artifacts between jobs. The latest (v4) upload-artifact and download-artifact actions are not supported for some reason, so I had to rely on the deprecated v3 version.
Aside from that I encountered some issues with "kubectl cp" command as it could not preserve the original file permissions when copying the Quartz files into the PVC - I had to copy them to a temp location and change their ownership to UID 1000 and GID 1000 as the NFS PVC did not allow files owned by root (UID 0, GID 0).