An earlier commit (22acad8) pointed these at git.boglabob.com under the
assumption it was a canonical alias target for the server. Checking the
real zone file shows every other hostname (git, photos, music, etc.) is
a CNAME straight to the bare apex boglabob.com instead - git.boglabob.com
isn't special, just one more independent CNAME. Fix podinfo/hello-app to
match.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
FORGEJO_TOKEN now has both repository read (needed for the archive-based
checkout) and write:package (needed for the kaniko push) - confirmed via
a direct curl test against the archive endpoint returning 200.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
FORGEJO_TOKEN now has package:write scope, and FORGEJO_USER/FORGEJO_ORG
have been moved from repo Secrets to repo Variables where ${{ vars.X }}
actually reads from.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
The last failure was identical to the one before the /tmp -> workspace
fix, byte for byte - meaning github.workspace resolves to /tmp itself in
this runner, and the real gap was that nothing creates that directory
before our step runs (actions/checkout@v4 normally does this itself;
plain wget doesn't). mkdir -p it first, and echo the resolved path so a
third failure isn't another blind guess.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
Forgejo's re-run replayed the workflow file as it was at the original
triggering commit, not the fixed version now on main - needs an actual
new push touching apps/hello-app/src/** to pick it up.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
/tmp doesn't exist in the kaniko executor:debug image (confirmed - no
standard FHS layout there at all), so the wget -O target failed with
"No such file or directory". Write into github.workspace instead, which
is known to exist since the build step already uses it.
Also adds the step-7 desktop-vs-k8s clarification from earlier.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
actions/checkout@v4 needs a Node.js runtime, which the kaniko executor:debug
image doesn't have and has no package manager to install it with (confirmed
via a throwaway podman run - no git, no node, not even /etc/os-release).
Fetch the repo as a tarball from Forgejo's archive endpoint instead, using
wget/tar, which are actually present in the image.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
- Distinguish the runner registration token from FORGEJO_TOKEN explicitly
(easy to mix up, causes a confusing "registration token not found" error)
- Split register/daemon into two commands: register is one-shot and exits,
running only it under --restart unless-stopped silently loops forever
instead of ever listening for a job
- Add --userns=keep-id, needed so the container can open the rootless
Podman socket (owned by k8s's host UID, not the container's remapped one)
- Note that <FORGEJO_USER>/<FORGEJO_TOKEN> are placeholders to replace,
not literal syntax, since bash reads a bare <word> as redirection
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
The two commands under step 4 show what imperative Helm install would
look like for comparison, not something to actually run - helm isn't
installed anywhere in this project since Flux handles it declaratively.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
Previous version listed commands with light justification; this
explains the actual mechanism at each stage - qemu:///system vs
session, why pools mediate permissions, COW overlays, what cloud-init's
two data files are for, what each virt-install flag does, what a
kubeconfig actually contains, and (the deepest gap) what flux bootstrap
concretely does under the hood: the controllers/CRDs involved, what
GitRepository and Kustomization objects actually do on their reconcile
loops, why apps.yaml gets picked up automatically, and how the auth
Secret works - with kubectl/flux commands to go verify each claim
against the already-bootstrapped cluster rather than take it on faith.
Rename k8s's key from the custom k3s_homelab to the default
id_ed25519 - the custom name had no real justification (k8s is a
fresh account with nothing to collide with) and caused a real bug:
OpenSSH only auto-offers default-named keys, so ssh commands lacking
an explicit -i silently failed to authenticate. Also add the
never-actually-documented kubectl install step, and mkdir -p ~/.kube
before the first redirect into it, in both SETUP.md and QUICKSTART.md.
Debian's libvirt-daemon-system doesn't auto-create a default storage
pool (network exists but inactive) - added explicit pool-define/build/
start and net-start steps. Also fixed --cloud-init user-data=~/... not
expanding (tilde only expands at start of a shell word, not after =),
and noted why --os-variant may need to be an older release than the
actual image if osinfo-db is stale.
Disk images under k8s's home directory aren't readable by the
libvirt-qemu user that actually runs VMs under qemu:///system. Use
libvirt's own default storage pool (vol-create-as/vol-upload) instead,
so libvirtd handles file ownership rather than k8s directly, and pin
LIBVIRT_DEFAULT_URI=qemu:///system throughout.
