Cross-referencing image-automation.yaml's own comment explaining the
namespace-matching bug that caused Setters to silently no-op for hours
of investigation - worth calling out in the walkthrough itself since it
fails with no error at all, just an endless "repository up-to-date".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
ImageUpdateAutomation only lists ImagePolicy objects in its own
namespace (image-automation-controller's getPolicies() scopes the
List() to obj.Namespace, confirmed by reading v1.2.4 source) - the
$imagepolicy marker's namespace:name is only used to match against
that pre-filtered list, not to broaden the search. Our
ImageUpdateAutomation lived in flux-system while its ImagePolicy
lived in hello-app, so the policy was invisible and Setters always
found zero markers to update ("repository up-to-date" forever),
regardless of correct marker syntax/RBAC/policy resolution.
Moved ImageUpdateAutomation into the hello-app namespace (alongside
its ImagePolicy), keeping a cross-namespace sourceRef back to the
flux-system GitRepository. Also fixed the commit messageTemplate,
which used the removed .Updated field (v1.2.4 requires .Changed).
Verified live: Flux pushed commit 0273f15 updating deployment.yaml's
tag on its own, and the cluster rolled out that image without any CI
involvement. Removed the update-deployment-tag CI workaround job
accordingly - it's redundant now and would otherwise race with
Flux's own commits.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GJNvvV3RrvX6TRZGAKEUeY
ImageUpdateAutomation's Setters strategy never actually commits despite a
verified-correct $imagepolicy marker, correct ImagePolicy resolution, and
a from-scratch Flux bootstrap against a fresh controller - root cause
unresolved after extensive investigation. Add a second job that commits
the built tag straight to deployment.yaml using git (the kaniko image has
no git/node, hence the separate alpine/git container), passing the tag
via job outputs from the build step. ImageRepository/ImagePolicy stay in
place for visibility into available tags even though nothing consumes
their resolution anymore.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
Remove the throwaway setter-test.yaml and revert update.path to
./apps/hello-app. Root cause of ImageUpdateAutomation never committing a
tag update remains unresolved after exhausting marker syntax, path
scoping, field structure, namespace placement, RBAC, and version
compatibility as candidates - all checked out fine individually. Moving
on to docs/04-tofu.md; may retest after Flux gets a fresh bootstrap
against the new cluster there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
Every official Flux example uses the same namespace for ImagePolicy and
ImageUpdateAutomation; our setup splits them (ImagePolicy in hello-app,
ImageUpdateAutomation in flux-system). Testing whether that cross-namespace
split is the actual blocker, despite being documented as supported.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
Isolating whether Setters can find/update anything at all in this repo,
independent of the Deployment's nested containers[].image structure -
throwaway, will be removed once resolved.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
Diagnostic change - narrower ./apps/hello-app path never found anything
to update despite a byte-verified-correct marker, matching ImagePolicy
resolution, and no RBAC/duplicate-resource issues. Testing whether the
nested path itself is the problem before looking further.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
The $imagepolicy marker was on the line above image:, not a trailing
comment on that line. Flux's Setters strategy attaches YAML comments to
the node on their own line, so a marker on a preceding line never
associates with the field below it - the marker silently matched nothing,
which is why ImageUpdateAutomation logged "repository up-to-date" on
every reconcile regardless of what ImagePolicy resolved to, and never
once committed a tag update despite two successful image builds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
docs/03-flux.md: clarify that podinfo/hello-app pointing at the same
<VM_IP> in Caddy isn't a routing choice - there's only one VM right now,
doubling as both control plane and workload node, and Traefik is what
actually does per-hostname routing once the request lands there.
index.html: drop the specific "Dell T630" hardware reference from the
public-facing tagline in favor of a generic "Home server".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
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.
