🤖 Generated by the Agentic Engineer
Three findings were raised against plugins/gitops-kubernetes/skills/ during the
semantic review of #162 (fluxcd/agent-skills v0.2.0 → v0.3.0). All three are valid.
None is fixable in this repository: those files are synced third-party artifacts
(metadata.github-repo: https://github.com/fluxcd/agent-skills), so an edit here is
reverted by the updater workflow with no conflict and no CI signal. Reporting them to
a third-party project needs the maintainer's explicit per-artifact approval, which an
unattended run cannot obtain — hence this issue.
The findings
1. --envsubst sources the dotenv as shell code (P1, gitops-repo-audit/scripts/validate.sh)
load_envsubst() runs set -o allexport; source "$envsubst_file". In the audit
workflow that dotenv can be generated from the repository being audited, so an entry
like VALUE=$(some-command) executes with the auditor's or CI job's credentials before
validation begins. The fix is to parse and export only valid KEY=VALUE assignments
without shell evaluation.
2. envsubst inherits the caller's environment (P2, same file)
Because the dotenv is sourced into the current shell, every already-exported variable
stays visible to flux envsubst. An ambient CI variable whose name appears in the
audited YAML then substitutes silently — hiding a genuinely missing ConfigMap value,
and potentially copying a CI secret into the -b bundle the auditor reads afterwards.
Invoking envsubst with an environment containing only the parsed assignments fixes both.
3. Digest-pinned example contradicts Flux image semantics (P2, gitops-knowledge/references/monorepo-delivery.md)
Setting digest makes Flux ignore newTag, per the field index bundled in the same PR
(assets/schemas/kustomization-kustomize-v1.fields.txt). The example therefore renders
${app_registry}/<app>@<digest>, not the :<tag>@<digest> the prose promises, and the
added eval asserts that unattainable form.
Scope
Findings 1 and 2 are on a path that is opt-in (-E/--envsubst, new in v0.3.0 and
absent by default), and nothing in this suite invokes it, so vendoring this version does
not activate the exposure. Finding 3 is documentation: a misleading example, not broken
runtime behaviour.
What this issue is asking for
Maintainer approval to report findings 1 and 2 upstream to fluxcd/agent-skills — and,
before opening anything there, a check of that project's stated policy on AI-assisted
contributions, per the contribution rules. Finding 3 can ride along or be dropped as
editorial.
Three findings were raised against
plugins/gitops-kubernetes/skills/during thesemantic review of #162 (
fluxcd/agent-skillsv0.2.0 → v0.3.0). All three are valid.None is fixable in this repository: those files are synced third-party artifacts
(
metadata.github-repo: https://github.com/fluxcd/agent-skills), so an edit here isreverted by the updater workflow with no conflict and no CI signal. Reporting them to
a third-party project needs the maintainer's explicit per-artifact approval, which an
unattended run cannot obtain — hence this issue.
The findings
1.
--envsubstsources the dotenv as shell code (P1,gitops-repo-audit/scripts/validate.sh)load_envsubst()runsset -o allexport; source "$envsubst_file". In the auditworkflow that dotenv can be generated from the repository being audited, so an entry
like
VALUE=$(some-command)executes with the auditor's or CI job's credentials beforevalidation begins. The fix is to parse and export only valid
KEY=VALUEassignmentswithout shell evaluation.
2. envsubst inherits the caller's environment (P2, same file)
Because the dotenv is sourced into the current shell, every already-exported variable
stays visible to
flux envsubst. An ambient CI variable whose name appears in theaudited YAML then substitutes silently — hiding a genuinely missing ConfigMap value,
and potentially copying a CI secret into the
-bbundle the auditor reads afterwards.Invoking envsubst with an environment containing only the parsed assignments fixes both.
3. Digest-pinned example contradicts Flux image semantics (P2,
gitops-knowledge/references/monorepo-delivery.md)Setting
digestmakes Flux ignorenewTag, per the field index bundled in the same PR(
assets/schemas/kustomization-kustomize-v1.fields.txt). The example therefore renders${app_registry}/<app>@<digest>, not the:<tag>@<digest>the prose promises, and theadded eval asserts that unattainable form.
Scope
Findings 1 and 2 are on a path that is opt-in (
-E/--envsubst, new in v0.3.0 andabsent by default), and nothing in this suite invokes it, so vendoring this version does
not activate the exposure. Finding 3 is documentation: a misleading example, not broken
runtime behaviour.
What this issue is asking for
Maintainer approval to report findings 1 and 2 upstream to
fluxcd/agent-skills— and,before opening anything there, a check of that project's stated policy on AI-assisted
contributions, per the contribution rules. Finding 3 can ride along or be dropped as
editorial.