gitlab-runner register drops some arguments based on order
Summary
When running gitlab-runner register
with command line arguments, some arguments are ignored based on where they appear in the list.
Steps to reproduce
Example of full parsing of arguments
gitlab-runner register --non-interactive \
--url $GITLAB_URL \
--executor kubernetes \
--kubernetes-namespace gitlab \
--kubernetes-cpu-limit "1000m" \
--kubernetes-memory-limit "128Mi" \
--kubernetes-cpu-request "100m" \
--kubernetes-poll-interval 3 \
--kubernetes-poll-timeout 300 \
--kubernetes-memory-request "128Mi" \
--kubernetes-service-cpu-limit "1000m" \
--kubernetes-service-memory-limit "128Mi" \
--kubernetes-service-cpu-request "100m" \
--kubernetes-service-memory-request "128Mi" \
--kubernetes-helper-cpu-limit "1000m" \
--kubernetes-helper-memory-limit "128Mi" \
--kubernetes-helper-cpu-request "100m" \
--kubernetes-helper-memory-request "128Mi" \
--kubernetes-image "ubuntu:16.04" \
--kubernetes-privileged "true"
Example of incomplete parsing of arguments
gitlab-runner register --non-interactive \
--url $GITLAB_URL \
--executor kubernetes \
--kubernetes-image "ubuntu:16.04" \
--kubernetes-privileged "true" \
--kubernetes-namespace gitlab \
--kubernetes-cpu-limit "1000m" \
--kubernetes-memory-limit "128Mi" \
--kubernetes-cpu-request "100m" \
--kubernetes-poll-interval 3 \
--kubernetes-poll-timeout 300 \
--kubernetes-memory-request "128Mi" \
--kubernetes-service-cpu-limit "1000m" \
--kubernetes-service-memory-limit "128Mi" \
--kubernetes-service-cpu-request "100m" \
--kubernetes-service-memory-request "128Mi" \
--kubernetes-helper-cpu-limit "1000m" \
--kubernetes-helper-memory-limit "128Mi" \
--kubernetes-helper-cpu-request "100m" \
--kubernetes-helper-memory-request "128Mi"
Note that --kubernetes-image
and --kubernetes-privileged
are located higher in the list
Actual behavior
When running the problematic invocation, /etc/gitlab-runner/config.toml
has
[[runners]]
name = "redacted"
url = "redacted"
token = "redacted"
executor = "kubernetes"
[runners.cache]
[runners.kubernetes]
host = ""
image = "ubuntu:16.04"
namespace = ""
namespace_overwrite_allowed = ""
privileged = true
service_account_overwrite_allowed = ""
[runners.kubernetes.volumes]
Expected behavior
Both should result in the same output, which happens on the non-problematic invocation
[[runners]]
name = "redacted"
url = "redacted"
token = "redacted"
executor = "kubernetes"
[runners.cache]
[runners.kubernetes]
host = ""
image = "ubuntu:16.04"
namespace = "gitlab"
namespace_overwrite_allowed = ""
privileged = true
cpu_limit = "1000m"
memory_limit = "128Mi"
service_cpu_limit = "1000m"
service_memory_limit = "128Mi"
helper_cpu_limit = "1000m"
helper_memory_limit = "128Mi"
cpu_request = "100m"
memory_request = "128Mi"
service_cpu_request = "100m"
service_memory_request = "128Mi"
helper_cpu_request = "100m"
helper_memory_request = "128Mi"
poll_interval = 3
poll_timeout = 300
service_account_overwrite_allowed = ""
[runners.kubernetes.volumes]
Relevant logs and/or screenshots
I believe the above section is sufficient. There are no errors provided to me on the problematic invocation.
Environment description
Custom integration of gitlab in a kubernetes environment.
Chart is a bit of a fork gitlab-ce chart and gitlab-runner fork .. runner hasn't been updated with new code because of this issue.
If it means anything, Kubernetes 1.6 w/ rbac
Used GitLab Runner version
I was using gitlab/gitlab-runner:v9.5.0
docker image inside of a pod in kubernetes.