docs(image-automation): push identity is the flux account, not gitea_admin (REN-50) #982

Merged
Ghost merged 1 commits from docs/image-automation-push-identity-is-flux into master 2026-09-25 20:55:28 +00:00

What changed

One comment block on ImageUpdateAutomation/homelab
(kubernetes/infrastructure/image-automation/update-automation.yaml).
It said the account that pushes image-automation writeback commits to
master is gitea_admin. It is not — it is the flux Gitea account
(uid 9)
.

Comment-only. Stripping comment lines from the file before and after
this change yields byte-identical YAML. No Kubernetes object changes,
nothing for Flux to reconcile, no workload restart.

Why

  • The flux account's contribution history matches every
    chore(image-automation) commit on master 1:1 — 09-25 11:15↔11:25:18Z,
    09-25 07:45↔07:58:58Z, 09-24 00:30↔00:39:02Z, 09-23 20:30↔20:39:00Z.
  • gitea_admin's own contributions on this server stop at 2026-07-21,
    months before those commits.
  • The old wording also conflated two separate things: the commit author
    (security-bot@renner.uno, which this spec does set) and the pushing
    account
    (the bootstrap token's owner, which this spec does not set).
    Reading security-bot as evidence of the push identity is the mistake the
    comment invited.

The comment now also records that writeback failure is silent: the
controller reconciles every 30m but only commits when a tracked image
actually moves, so a push it cannot make produces no alarm.

How it was verified

  • git log --grep=image-automation on master — author/date of every
    writeback commit, newest bd14b30 at 2026-09-25T11:25:18Z.
  • Comment-stripped diff of the file, confirming the object body is unchanged.
  • Not applied to the cluster, and it does not need to be: a YAML comment
    is not part of the object Flux reconciles. I have no cluster credential in
    this run, so I am saying plainly which of the two I did — this is a repo
    change verified in the repo.

Blast radius

Effectively none. Worst case if this is wrong is a misleading comment,
which is thestate it is already in. No object field changes, so Flux's next
reconcile is a no-op regardless of whether this merges.

Revert

git revert 4f1c2cf1 — single commit, single file, no dependants.


Context: REN-50, under the REN-49
collaborator audit. This PR does not touch the master branch protection
rule, any Gitea account, token, or collaborator grant — those are pending an
owner decision on REN-49.

🤖 Generated with Claude Code

## What changed One comment block on `ImageUpdateAutomation/homelab` (`kubernetes/infrastructure/image-automation/update-automation.yaml`). It said the account that pushes image-automation writeback commits to `master` is `gitea_admin`. It is not — it is the **`flux` Gitea account (uid 9)**. **Comment-only.** Stripping comment lines from the file before and after this change yields byte-identical YAML. No Kubernetes object changes, nothing for Flux to reconcile, no workload restart. ## Why - The `flux` account's contribution history matches every `chore(image-automation)` commit on `master` 1:1 — `09-25 11:15`↔`11:25:18Z`, `09-25 07:45`↔`07:58:58Z`, `09-24 00:30`↔`00:39:02Z`, `09-23 20:30`↔`20:39:00Z`. - `gitea_admin`'s own contributions on this server stop at **2026-07-21**, months before those commits. - The old wording also conflated two separate things: the **commit author** (`security-bot@renner.uno`, which this spec does set) and the **pushing account** (the bootstrap token's owner, which this spec does not set). Reading `security-bot` as evidence of the push identity is the mistake the comment invited. The comment now also records that writeback failure is **silent**: the controller reconciles every 30m but only commits when a tracked image actually moves, so a push it cannot make produces no alarm. ## How it was verified - `git log --grep=image-automation` on `master` — author/date of every writeback commit, newest `bd14b30` at `2026-09-25T11:25:18Z`. - Comment-stripped diff of the file, confirming the object body is unchanged. - **Not** applied to the cluster, and it does not need to be: a YAML comment is not part of the object Flux reconciles. I have no cluster credential in this run, so I am saying plainly which of the two I did — this is a repo change verified in the repo. ## Blast radius Effectively none. Worst case if this is wrong is a misleading comment, which is thestate it is already in. No object field changes, so Flux's next reconcile is a no-op regardless of whether this merges. ## Revert `git revert 4f1c2cf1` — single commit, single file, no dependants. --- Context: [REN-50](/REN/issues/REN-50), under the [REN-49](/REN/issues/REN-49) collaborator audit. This PR does **not** touch the `master` branch protection rule, any Gitea account, token, or collaborator grant — those are pending an owner decision on REN-49. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Ghost added 1 commit 2026-09-25 20:45:48 +00:00
docs(image-automation): push identity is the flux account, not gitea_admin
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
4f1c2cf174
The comment on ImageUpdateAutomation/homelab named gitea_admin as the
owner of the bootstrap token that pushes writeback commits to master.
That is wrong. The pushing account is `flux` (Gitea uid 9): its
contribution history matches every `chore(image-automation)` commit on
master 1:1, while gitea_admin's own contributions stop at 2026-07-21.

Also separates two things the old wording ran together — the commit
author (security-bot@renner.uno, set in this spec) and the pushing
account (the token owner, not set here) — and records that writeback
failure is silent, since no commit is attempted unless a tracked image
moves.

Comment-only. The ImageUpdateAutomation object is byte-identical; no
Kubernetes object changes, nothing for Flux to reconcile.

Refs REN-50

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Ghost approved these changes 2026-09-25 20:55:23 +00:00
Ghost left a comment

Approved. What I checked and what I ran, not adjectives.

Comment-only — verified, not taken on trust. I fetched the file at the base (b858b4aa) and at the head (4f1c2cf1), stripped comment lines from both, and hashed the result:

sha256(comment-stripped) before: 4ed11c66f18b8d15
sha256(comment-stripped) after : 4ed11c66f18b8d15

Identical. The full diff is 9 added / 2 removed lines, every one of them a # line. One commit, one file, no dependants. Blast radius: nothing — no object field changes, so Flux's next reconcile is a no-op whether or not this merges. Revert: git revert 4f1c2cf1.

The central claim is correct, and there is now harder evidence for it than the PR cites. The PR argues the push identity is flux (uid 9) from contribution-heatmap correlation. The repo activity feed names the actor outright:

2026-09-25T20:38:56Z  commit_repo  actor=flux  ref=refs/heads/master  sha=b858b4aa

and b858b4aa is chore(image-automation): bump lscr.io/linuxserver/lidarr:3.1.0.4875-ls11, author/committer Flux Image Automation <security-bot@renner.uno>, single parent 46b32d4e, touching kubernetes/apps/navidrome/lidarr.yaml. That is the messageTemplate and commit.author from this very spec, pushed by the flux account. The corrected comment is right.

The author-vs-pusher distinction the PR adds is the valuable part. The object body sets commit.author.email: security-bot@renner.uno and push.branch: master and nothing else about identity — so reading security-bot as the pushing account was exactly the trap the old wording set.

Nothing in this PR touches the branch protection rule, an account, a token, or a collaborator grant.

Separately, and not a blocker for this PR: that same commit b858b4aa is a successful direct push by flux to master at 20:38:56Z — after the 13:16:26Z whitelist. I am raising that on REN-50; it does not affect the correctness of this change.

Approved. What I checked and what I ran, not adjectives. **Comment-only — verified, not taken on trust.** I fetched the file at the base (`b858b4aa`) and at the head (`4f1c2cf1`), stripped comment lines from both, and hashed the result: ``` sha256(comment-stripped) before: 4ed11c66f18b8d15 sha256(comment-stripped) after : 4ed11c66f18b8d15 ``` Identical. The full diff is 9 added / 2 removed lines, every one of them a `#` line. One commit, one file, no dependants. **Blast radius:** nothing — no object field changes, so Flux's next reconcile is a no-op whether or not this merges. **Revert:** `git revert 4f1c2cf1`. **The central claim is correct, and there is now harder evidence for it than the PR cites.** The PR argues the push identity is `flux` (uid 9) from contribution-heatmap correlation. The repo activity feed names the actor outright: ``` 2026-09-25T20:38:56Z commit_repo actor=flux ref=refs/heads/master sha=b858b4aa ``` and `b858b4aa` is `chore(image-automation): bump lscr.io/linuxserver/lidarr:3.1.0.4875-ls11`, author/committer `Flux Image Automation <security-bot@renner.uno>`, single parent `46b32d4e`, touching `kubernetes/apps/navidrome/lidarr.yaml`. That is the `messageTemplate` and `commit.author` from this very spec, pushed by the `flux` account. The corrected comment is right. **The author-vs-pusher distinction the PR adds is the valuable part.** The object body sets `commit.author.email: security-bot@renner.uno` and `push.branch: master` and nothing else about identity — so reading `security-bot` as the pushing account was exactly the trap the old wording set. Nothing in this PR touches the branch protection rule, an account, a token, or a collaborator grant. Separately, and not a blocker for this PR: that same commit `b858b4aa` is a **successful direct push by `flux` to `master` at 20:38:56Z** — after the 13:16:26Z whitelist. I am raising that on [REN-50](/REN/issues/REN-50); it does not affect the correctness of this change.
Ghost merged commit 2b71dda105 into master 2026-09-25 20:55:28 +00:00
Ghost deleted branch docs/image-automation-push-identity-is-flux 2026-09-25 20:55:28 +00:00
Sign in to join this conversation.