Getting ready for CI/CD
Build and Deploy / deploy (push) Failing after 32s

This commit is contained in:
2026-05-20 09:44:49 +03:00
parent 3b98043a61
commit 818d253a07
5 changed files with 94 additions and 2 deletions
+23
View File
@@ -0,0 +1,23 @@
name: Build and Deploy
on:
push:
branches: [master]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: nix --extra-experimental-features 'nix-command flakes' build
- name: Deploy to Cloudflare Pages
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
run: |
npx --yes wrangler@3 pages deploy result/ \
--project-name=personal-site \
--commit-dirty=true
+1
View File
@@ -4,3 +4,4 @@ public/
result
result-*
.direnv
.wrangler
+50 -1
View File
@@ -95,5 +95,54 @@ nix flake update
* Deployment
The site is deployed to Cloudflare Pages automatically on push via a Gitea Actions
workflow running on a Raspberry Pi runner (=aarch64-linux=).
workflow (=.gitea/workflows/deploy.yml=) running on a Raspberry Pi runner (=aarch64-linux=).
The =nix build= output is uploaded directly as the Pages deployment artifact.
** First-time setup
*** 1. Create a Cloudflare Pages project
In the Cloudflare dashboard → Pages → Create a project → *Direct Upload*.
Name it =personal-site= (must match the =--project-name= flag in the workflow).
Skip the initial upload — CI will handle it.
Alternatively, create it with Wrangler locally:
#+begin_src sh
npx wrangler pages project create personal-site
#+end_src
*** 2. Get your Cloudflare credentials
- *Account ID*: Cloudflare dashboard → right sidebar, or any zone overview page.
- *API Token*: My Profile → API Tokens → Create Token.
Use the *Edit Cloudflare Pages* template, or create a custom token with:
- Permission: =Cloudflare Pages==Edit=
- Account resource: your account
*** 3. Add secrets to Gitea
In the Gitea repo → Settings → Secrets → Actions, add:
| Secret name | Value |
|--------------------------+------------------------------|
| =CLOUDFLARE_API_TOKEN= | the API token from step 2 |
| =CLOUDFLARE_ACCOUNT_ID= | your numeric account ID |
*** 4. Verify the runner label
The workflow uses =runs-on: ubuntu-latest=.
Check your Gitea runner's label in *Site Administration → Runners* and update the
workflow if your runner uses a different label (e.g. =nix=, =self-hosted=, etc.).
The runner needs *Nix* (with flakes enabled) and *Node.js* on =PATH=.
If Node.js is not available system-wide you can prepend the build step with:
#+begin_src sh
nix-shell -p nodejs --run "npx --yes wrangler@3 pages deploy ..."
#+end_src
*** 5. Push to master
The workflow triggers on every push to =master=.
Check the Actions tab in Gitea to monitor runs.
@@ -0,0 +1,19 @@
#+TITLE: Emacs + Nix + Org config
#+DATE: 2026-05-14
* Background for the uninitiated
My personal workspace configuration is written in Nix nowadays (shocker), and the repo itself is about two years old.
However, since I live in Emacs, most of the configuration lives in the =.org= files that define my Emacs experience, and these files have been through a few repos. Going back, I found the first commit of a config file that would later become what I use today. It is dated February 2020, so barely pre-covid.
I currently have thousands of lines determining my Emacs experience, and so the use of ORG mode is really good for me. The configuration files themselves have thousands of lines of code. ORG mode configuration provides two key benefits:
- Structure: with thousands of lines of code, it is easy to get lost. ORG mode makes navigating between levels and headings easy, allowing me to section off areas of the file for different aspects of the configuration.
- Context: the ability to write also in plain English allows me to document oddities in the configuration very easily. This could be done with comments of course, but I find having the ability to write very readable English easily
makes me document more often.
* Fast-forward to today
Nowadays I have a NIX site.
ur
+1 -1
View File
@@ -174,7 +174,7 @@ EOF
packages.default = site;
devShells.default = pkgs.mkShell {
packages = [ new-post new-thing ];
packages = [ new-post new-thing pkgs.nodejs ];
};
apps = {