## Summary Summarized [here](https://gitlab.com/gitlab-org/charts/gitlab-runner/issues/78#note_215186596) but the gitlab-runner images have inconsistent UIDs. This making developing a consistent helm chart problematic. In kubernetes you need to specify the uid that will run the process. gitlab-runner:ubuntu image has a user named gitlab-runner user with uid 999 gitlab-runner:ubuntu image has a user named _apt user with uid 100 gitlab-runner:alpine image has a gitlab-runner user with uid 100 Attempt to use the gitlab-runner:ubuntu image with the default helm chart using uid 100. However if you change the user in helm you then will no longer be able to deploy gitlab-runner:alpine ## Actual behavior When the ubuntu image runs the runner registers but fails to properly setup the runner due to permission issues. ## Expected behavior The runner should successfully register. ## Suggest Fix Pre create the gitlab-runner user with uid 999, before runner starts. As normally the runner will just create the user dynamically for if it doesn't exist. This should be applied to both alpine, and ubuntu images `adduser gitlab-runner -u 999 -G nogroup -h /home/gitlab-runner -s /sbin/nologin -D -S` **We need to be careful** to roll this out in a backward compatible way since users can use our helper image as a base image to build their own helper image and have configured their own security policies to allow certain UID/GID