fix(deployment): run plugin container as the reposilite user
Helm / helm-lint (push) Successful in 8s
Helm / helm-unittest (push) Successful in 27s
Generate README / generate-parameters (push) Successful in 42s
Markdown linter / markdown-link-checker (push) Successful in 38s
Markdown linter / markdown-lint (push) Successful in 42s
Release / publish-chart (push) Successful in 1m16s
Helm / helm-lint (push) Successful in 8s
Helm / helm-unittest (push) Successful in 27s
Generate README / generate-parameters (push) Successful in 42s
Markdown linter / markdown-link-checker (push) Successful in 38s
Markdown linter / markdown-lint (push) Successful in 42s
Release / publish-chart (push) Successful in 1m16s
The reposilite entrypoint chowns /app to 977:977 whenever it starts as root. The plugin container downloaded the jar as its own image user (101), so after the first start the file was owned by 977:977 with mode 0644. Since the plugins emptyDir survives a container restart within the same pod, a restarted plugin container could no longer overwrite the existing jar and aborted with "Permission denied", which left the pod in a permanent Init:CrashLoopBackOff until the pod itself was recreated. Run the plugin container as 977:977 by default and expose the security context as deployment.pluginContainer.securityContext, so it can be aligned when PUID/PGID are overridden. Co-authored-by: Copilot <copilot@github.com>
This commit is contained in:
@@ -30,6 +30,9 @@ tests:
|
||||
- https://reposilite.com/plugins/prometheus.jar
|
||||
name: download-prometheus-plugin
|
||||
image: docker.io/curlimages/curl:0.1.0
|
||||
securityContext:
|
||||
runAsGroup: 977
|
||||
runAsUser: 977
|
||||
volumeMounts:
|
||||
- mountPath: /app/data/plugins
|
||||
name: plugins
|
||||
|
||||
Reference in New Issue
Block a user