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