mirror of
https://github.com/dredx/prole.git
synced 2026-09-23 12:03:59 +00:00
- Add centralized config resolver/activator with per-environment layering and stable symlink entrypoint\n- Bootstrap missing env dirs and preserve non-symlink legacy prole.cfg by seeding into inferred env\n- Wire installer UI/backend + shell helpers to shared resolution path for explicit, safe env switching\n- Harden k3d: registry network/DNS wiring and ArgoCD repo-server hostPath permission init\n- Add docs + regression tests for env switching, namespace stability, k3d registry, and ArgoCD rollout Co-authored-by: Junie <junie@jetbrains.com>
952 B
952 B
k3d notes
ArgoCD repo-server: copyutil ... Permission denied
If ArgoCD deploy appears to stall on argocd-repo-server and logs show:
copyutil /bin/cp: cannot create regular file '/var/run/argocd/argocd': Permission denied
This is usually a hostPath permission issue.
Why it happens
In k3d, hostPath volumes refer to paths on the k3d node containers' filesystems.
When a manifest uses hostPath.type: DirectoryOrCreate, Kubernetes creates the
directory on the node as root:root with restrictive permissions.
ArgoCD runs argocd-repo-server and its init containers as a non-root user by
default, so an init container like copyutil cannot write to /var/run/argocd
unless the volume path is writable.
How Prole avoids the stall
The Prole ArgoCD manifest includes an init-permissions initContainer (running
as root) which prepares/chowns the hostPath-backed mount points before the
non-root init containers run.