minified markdown a bit

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",

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",

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

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.