OneDev uses custom trusted certificates from /opt/onedev/conf/trust-certs
Problem:
Kubernetes workspaces fail to start when custom trusted certificates are configured in OneDev.
This currently also prevents AI pull request reviews from running, as recent OneDev versions create a workspace to perform the review.
The repository itself is cloned successfully. However, the workspace initialization fails while attempting to change the ownership of /onedev-workspace:
Downloading user data 'codex'...
chown: changing ownership of '/onedev-workspace/trust-certs': Read-only file system
chown: changing ownership of '/onedev-workspace/trust-certs/..data': Read-only file system
chown: changing ownership of '/onedev-workspace/trust-certs/1.pem': Read-only file system
io.onedev.commons.utils.ExplicitException: Command execution failed
(command: chown -R 1001:1001 /onedev-workspace, exit code: 1)
at io.onedev.k8shelper.KubernetesHelper.changeOwner(KubernetesHelper.java:458)
at io.onedev.k8shelper.WorkspaceHelper.init(WorkspaceHelper.java:194)
at io.onedev.k8shelper.WorkspaceInit.main(WorkspaceInit.java:17)
The init container exits with code 1, after which the workspace is stopped.
Suspected cause:
KubernetesProvisioner creates a ConfigMap containing OneDev's trusted certificates and mounts it at:
/onedev-workspace/trust-certs
Kubernetes ConfigMap volumes are read-only. The WorkspaceInit container subsequently runs:
chown -R <runAs> /onedev-workspace
The recursive ownership change enters the nested ConfigMap mount and fails, even though the actual workspace PVC is writable.
This appears to affect Kubernetes workspaces using a non-root Run As value whenever custom trusted certificates are configured.
Could you please have a look and confirm whether this is a bug or whether there is a recommended workaround?
Environment:
1dev/codexRun As:1001:1001/opt/onedev/conf/trust-certsProblem:
Kubernetes workspaces fail to start when custom trusted certificates are configured in OneDev.
This currently also prevents AI pull request reviews from running, as recent OneDev versions create a workspace to perform the review.
The repository itself is cloned successfully. However, the workspace initialization fails while attempting to change the ownership of
/onedev-workspace:The init container exits with code
1, after which the workspace is stopped.Suspected cause:
KubernetesProvisionercreates a ConfigMap containing OneDev's trusted certificates and mounts it at:Kubernetes ConfigMap volumes are read-only. The
WorkspaceInitcontainer subsequently runs:The recursive ownership change enters the nested ConfigMap mount and fails, even though the actual workspace PVC is writable.
This appears to affect Kubernetes workspaces using a non-root
Run Asvalue whenever custom trusted certificates are configured.Could you please have a look and confirm whether this is a bug or whether there is a recommended workaround?
Thank you very much!