Take in account registration token from secret
What does this MR do?
In the MR !398 (merged), the adaptation to the next Architecture token was not taking in account registration-token
provided by secret. This intended to correct it.
Why was this MR needed?
What's the best way to test this MR?
- Create a secret with registration token
gitlab-runner-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: gitlab-runner-secret
type: Opaque
stringData:
runner-registration-token: __REDACTED__
runner-token: ""
kubectl apply -f gitlab-runner-secret.yaml
- Use the following
values.yaml
values.yaml
image:
registry: registry.gitlab.com
image: gitlab-org/gitlab-runner
useTini: false
imagePullPolicy: IfNotPresent
replicas: 1
gitlabUrl: https://gitlab.com/
unregisterRunners: true
useJobNamespace: true
terminationGracePeriodSeconds: 0
concurrent: 1
checkInterval: 1
logLevel: "debug"
sessionServer:
enabled: false
annotations: {}
timeout: 1800
internalPort: 8093
externalPort: 9000
## For RBAC support:
rbac:
create: true
rules: []
clusterWideAccess: false
serviceAccountName: ""
serviceAccountAnnotations: {}
podSecurityPolicy:
enabled: false
resourceNames:
- gitlab-runner
metrics:
enabled: true
portName: metrics
port: 9252
serviceMonitor:
enabled: false
service:
enabled: false
type: ClusterIP
runners:
config: |
[[runners]]
[runners.kubernetes]
image = "alpine"
[[runners.kubernetes.services]]
name = "alpine:latest"
alias = "alpine-service"
command = ["sleep 900s"]
entrypoint = ["/bin/sh", "-c"]
# node_selector_overwrite_allowed = ".*"
locked: true
tags: "test"
runUntagged: true
protected: true
secret: gitlab-runner-secret
builds: {}
services: {}
helpers: {}
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: false
runAsNonRoot: false
podSecurityContext:
runAsUser: 100
fsGroup: 65533
resources:
requests:
memory: 128Mi
cpu: 100m
affinity: {}
nodeSelector: {}
tolerations: []
hostAliases: []
podAnnotations: {}
podLabels: {}
hpa: {}
secrets: []
configMaps: {}
volumeMounts: []
volumes: []
- Deploy Runner
- When the registration token is provided, the registration works as seen in the image below. All set tagged from the values.yaml are also set on the Runner.
- When the registration token is an authentication token, the registration still works. In my example, the registered runner through the UI is allow to run untagged jobs. Other options were left with their default values.
What are the relevant issue numbers?
Edited by Romuald Atchadé