Interpretation (optional)
customer-cisneros-w manages every Fleet resource through GitOps. Side-effect: every query, report, policy, and script in the Fleet UI shows the GitOps service account as the author, regardless of who actually wrote or last edited it.
For a small team this hides the most useful piece of context for triage: when a report breaks, "who last touched this?" becomes a git-log lookup instead of a glance at the resource. The customer expects that to get worse as more engineers contribute through GitOps.
The 4.71.0 "API-only user avatar" change visually distinguishes API users in the activity feed but doesn't carry the human identity behind a GitOps push, so it doesn't solve this.
Proposed
Surface the human author of GitOps-managed resources in Fleet, sourced from whatever identity the CI/CD runner can pass through (e.g. GITHUB_ACTOR, the merge-commit author, a workflow-supplied value).
Two levels, each useful on its own:
- Read the runner-supplied identity at apply time and store it on the resource as the author/last-editor on create or update. Display it in the UI alongside the GitOps service account.
- Optional richer signal: store both the original author (first commit that introduced the resource) and the last editor (most recent commit that touched the file).
Out of scope: Fleet doesn't need to deeply integrate with GitHub/GitLab. A workflow-supplied identifier passed through to fleetctl gitops is enough; product to decide the exact mechanism.
Workaround today
No native support today. Customer's interim plan:
- Standardise an author header comment block at the top of every YAML file. Reject PRs that don't include it.
- Use git history (
git blame, PR merge metadata) as the source of truth for "who last touched this".
Both work for cold-path investigations. Neither shows up in the Fleet UI, where most of the day-to-day triage happens.
Related
- 4.71.0: avatar for API-only users in the activity feed (visual signal only, doesn't carry human identity)
Interpretation (optional)
customer-cisneros-w manages every Fleet resource through GitOps. Side-effect: every query, report, policy, and script in the Fleet UI shows the GitOps service account as the author, regardless of who actually wrote or last edited it.
For a small team this hides the most useful piece of context for triage: when a report breaks, "who last touched this?" becomes a git-log lookup instead of a glance at the resource. The customer expects that to get worse as more engineers contribute through GitOps.
The 4.71.0 "API-only user avatar" change visually distinguishes API users in the activity feed but doesn't carry the human identity behind a GitOps push, so it doesn't solve this.
Proposed
Surface the human author of GitOps-managed resources in Fleet, sourced from whatever identity the CI/CD runner can pass through (e.g.
GITHUB_ACTOR, the merge-commit author, a workflow-supplied value).Two levels, each useful on its own:
Out of scope: Fleet doesn't need to deeply integrate with GitHub/GitLab. A workflow-supplied identifier passed through to
fleetctl gitopsis enough; product to decide the exact mechanism.Workaround today
No native support today. Customer's interim plan:
git blame, PR merge metadata) as the source of truth for "who last touched this".Both work for cold-path investigations. Neither shows up in the Fleet UI, where most of the day-to-day triage happens.
Related