Comment-only fix. No functional change — deploymentAnnotations and its value are untouched.
#311 landed a code comment asserting the Reloader annotation must sit on the Deployment rather than the pod template, and that "Reloader matches on the workload's own annotations". That is wrong, and it is currently on master.
I had reasoned from Reloader's documented workload-level behaviour plus a fleet-wide correlation: six workload-level-annotated resources had all been acted on, and three pod-template-level ones (authentik-server, authentik-worker, crowdsec-lapi) never had. That split looked like evidence. It was a confound — those three secrets simply had not changed yet.
A/B test: two identical Deployments consuming one Secret, differing only in annotation placement.
t+10s annot-on-podtemplate=gen2 annot-on-workload=gen2
reloader: Changes detected in 'test-secret' ...; updated 'annot-on-podtemplate' of type 'Deployment'
reloader: Changes detected in 'test-secret' ...; updated 'annot-on-workload' of type 'Deployment'
Reloader honours both placements and names each in its log.
Consequences of leaving the wrong comment in place: it would justify "fixing" authentik and crowdsec-lapi that are not broken, and it misstates how Reloader works for anyone who reads it later. deploymentAnnotations remains the right choice here, but for the honest reason — it matches the prevailing idiom in this repo, not because pod-template annotations are ineffective.
(This correction was pushed to the #311 branch after that PR had already been merged, so it never reached master. Hence a separate PR.)
Comment-only fix. No functional change — `deploymentAnnotations` and its value are untouched.
#311 landed a code comment asserting the Reloader annotation **must** sit on the Deployment rather than the pod template, and that "Reloader matches on the workload's own annotations". **That is wrong**, and it is currently on `master`.
I had reasoned from Reloader's documented workload-level behaviour plus a fleet-wide correlation: six workload-level-annotated resources had all been acted on, and three pod-template-level ones (`authentik-server`, `authentik-worker`, `crowdsec-lapi`) never had. That split looked like evidence. It was a confound — those three secrets simply had not changed yet.
A/B test: two identical Deployments consuming one Secret, differing only in annotation placement.
```
t+10s annot-on-podtemplate=gen2 annot-on-workload=gen2
reloader: Changes detected in 'test-secret' ...; updated 'annot-on-podtemplate' of type 'Deployment'
reloader: Changes detected in 'test-secret' ...; updated 'annot-on-workload' of type 'Deployment'
```
Reloader honours **both** placements and names each in its log.
Consequences of leaving the wrong comment in place: it would justify "fixing" authentik and crowdsec-lapi that are not broken, and it misstates how Reloader works for anyone who reads it later. `deploymentAnnotations` remains the right choice here, but for the honest reason — it matches the prevailing idiom in this repo, not because pod-template annotations are ineffective.
(This correction was pushed to the #311 branch after that PR had already been merged, so it never reached master. Hence a separate PR.)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The previous comment asserted the annotation "must" sit on the Deployment
rather than the pod template. That is wrong. An A/B test (two identical
Deployments consuming one Secret, differing only in annotation placement)
showed Reloader acting on BOTH within 10s, naming each in its log.
deploymentAnnotations is still used here, but only to match the prevailing
idiom in this repo — not because pod-template annotations are ineffective.
This also clears the suspicion raised against authentik-server,
authentik-worker and crowdsec-lapi: their placement is fine.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Comment-only fix. No functional change —
deploymentAnnotationsand its value are untouched.#311 landed a code comment asserting the Reloader annotation must sit on the Deployment rather than the pod template, and that "Reloader matches on the workload's own annotations". That is wrong, and it is currently on
master.I had reasoned from Reloader's documented workload-level behaviour plus a fleet-wide correlation: six workload-level-annotated resources had all been acted on, and three pod-template-level ones (
authentik-server,authentik-worker,crowdsec-lapi) never had. That split looked like evidence. It was a confound — those three secrets simply had not changed yet.A/B test: two identical Deployments consuming one Secret, differing only in annotation placement.
Reloader honours both placements and names each in its log.
Consequences of leaving the wrong comment in place: it would justify "fixing" authentik and crowdsec-lapi that are not broken, and it misstates how Reloader works for anyone who reads it later.
deploymentAnnotationsremains the right choice here, but for the honest reason — it matches the prevailing idiom in this repo, not because pod-template annotations are ineffective.(This correction was pushed to the #311 branch after that PR had already been merged, so it never reached master. Hence a separate PR.)
🤖 Generated with Claude Code