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