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?

1. 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

2. 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: []

3. Deploy Runner
4. 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.

Successful registration

5. 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.

Successful registration

What are the relevant issue numbers?

#436 (closed)