From 34df58168b96a74aa7e9aff23226bde890c03de4 Mon Sep 17 00:00:00 2001
From: Firq <me@firq.dev>
Date: Tue, 15 Apr 2025 22:32:31 +0200
Subject: [PATCH] minified markdown a bit
---
package-lock.json | 4 ++--
package.json | 2 +-
src/data/blog/deploying-this-round-2.md | 6 ++++--
src/data/blog/deploying-this.md | 11 +++++++++--
4 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/package-lock.json b/package-lock.json
index 0e3b4ad..525deb8 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,12 +1,12 @@
{
"name": "@firq/fgosite",
- "version": "0.2.0-pre.98",
+ "version": "0.2.0-pre.99",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"name": "@firq/fgosite",
- "version": "0.2.0-pre.98",
+ "version": "0.2.0-pre.99",
"dependencies": {
"@astro-community/astro-embed-youtube": "^0.5.6",
"@astrojs/check": "^0.9.4",
diff --git a/package.json b/package.json
index 1f57c89..cbfce88 100644
--- a/package.json
+++ b/package.json
@@ -1,7 +1,7 @@
{
"name": "@firq/fgosite",
"type": "module",
- "version": "0.2.0-pre.98",
+ "version": "0.2.0-pre.99",
"private": true,
"scripts": {
"dev": "astro dev",
diff --git a/src/data/blog/deploying-this-round-2.md b/src/data/blog/deploying-this-round-2.md
index 02e7aef..ffa3727 100644
--- a/src/data/blog/deploying-this-round-2.md
+++ b/src/data/blog/deploying-this-round-2.md
@@ -63,7 +63,6 @@ COPY --from=build /app/dist /public
COPY --from=build /app/serve.json /public/serve.json
RUN rm -r /public/assets/data/
-ENV PORT 8081
EXPOSE 8081
CMD [ "serve", "public/", "-p", "8081" ]
@@ -116,7 +115,8 @@ One last hurdle was, ironically, Gitlab. Specifically, it was their `lighthouse`
After some testing, I decided to just make my own version of the `lighthouse` container, without the user but with `unlighthouse` preinstalled (this also helps with processing times, as puppeteer takes a good amount of time to install each run).
-The `Dockerfile` can be found below (really simple again):
+<details>
+<summary>`Dockerfile` (really simple again)</summary>
```dockerfile
FROM node:20.10.0-bookworm
@@ -131,6 +131,8 @@ RUN apt-get update && apt-get -y install --no-install-recommends chromium=${CHRO
RUN npm install @unlighthouse/cli puppeteer
```
+</details>
+
With this container, the CI step to actually run the tests became a lot easier:
```yaml
diff --git a/src/data/blog/deploying-this.md b/src/data/blog/deploying-this.md
index 2599f0b..7c6e600 100644
--- a/src/data/blog/deploying-this.md
+++ b/src/data/blog/deploying-this.md
@@ -60,7 +60,9 @@ deploy-site:
```
First installing ssh and readying everything from the CI variables, this was a big change from the Pages configuration. But there was one thing that really bothered me: The ssh call. If you look at it, you can see that I left out the commands that are passed to `ssh`. There is a good reason: These are waaaay too long.
-If displayed as separated shell calls, they would look something like this:
+
+<details>
+<summary>commands formatted as a shell script</summary>
```shell
screen -X -S website-firq-npx kill;
@@ -78,6 +80,8 @@ cd ~;
screen -S website-firq-npx -dm npx serve public/ -p 9000 -c serve.json"
```
+</details>
+
With the following directory structure on the remote host, this can easily be explained:
```plain
@@ -172,7 +176,8 @@ After completing, the new stage begins.
Since the files are now built on the GitLab server and not in the Proxmox instance, the files need to be moved over during the pipeline. This can be achieved by a great utility known as `rsync`. It can be used for sending data via ssh to any client that supports it, which makes it the ideal tool for my use-case.
I also recommend looking <a href="https://blog.mitsunee.com/post/copy-steam-games-rsync" target="_blank" rel="noopener noreferrer">at this blog post from Mitsunee</a> detailing how to use `ssh` and `rsync` to sync game libraries to the Steam Deck with ease.
-In my case, the resulting `.gitlab-ci.yml` looked like this:
+<details>
+<summary>`.gitlab-ci.yml`</summary>
```yaml
deploy-site:
@@ -201,6 +206,8 @@ deploy-site:
- ssh $DEPLOY_USER@$DEPLOY_HOST "screen -S website-firq-npx -dm npx serve public/ -p 9000 -c serve.json"
```
+</details>
+
First, you have the rsync and ssh setup, which now also creates a new ssh-config for this. This really reduces the amount of arguments that need to be passed to ssh and rsync, making the whole flow less error-prone. My main issue with setting this up was to find out how to structure this, as I needed to setup ssh from the pipeline
without causing any weird issues. But by using a custom ssh-key and config, it became really easy to get this to run.