Answers: <p>I dealt with the same issue. Some people recommended using the Gitlab group "secrets" and using <code>before_script</code>. Since I knew I was also going to deploy and would need other tools on my runner like "helm", I made my own docker container. I still keep my config for my clusters in a base64 encoded group secret but I set it like this in the dockerfile.</p>
  
  <pre><code>ENV kube_config=$kube_config
  RUN echo -n ${kube_config} | base64 -d &gt; ~/.kube/config
  </code></pre>
  
  <p>Now just set an environment variable for your gitlab runner to point to your new image.</p>
  
  <pre><code>KUBERNETES_IMAGE: registry.gitlab.com/MY_USERNAME/MY_REPO_NAME/MY_IMAGE_NAME:latest
  </code></pre>
  
  <p>Don't forget to test your new container!</p>
  
  <pre><code>stages:
    - build
    - test
    - release
  
  variables:
    CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE/gitlab_runner:$CI_COMMIT_REF_NAME
    CONTAINER_RELEASE_IMAGE: $CI_REGISTRY_IMAGE/gitlab_runner:latest
  
  before_script:
    - apt-get update &amp;&amp; apt-get install docker.io -y
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  
  Build Image:
    stage: build
    script:
      - docker build --build-arg kube_config=${kube_config} -t ${CONTAINER_TEST_IMAGE} .
      - docker push ${CONTAINER_TEST_IMAGE}
    except:
      - master
  
  Test Kubectl:
    stage: test
    script:
      - docker pull ${CONTAINER_TEST_IMAGE}
      - docker run --rm ${CONTAINER_TEST_IMAGE} kubectl get deployments -n kube-system
    except:
      - master
  
  Test Helm:
    stage: test
    script:
      - docker pull ${CONTAINER_TEST_IMAGE}
      - docker run --rm ${CONTAINER_TEST_IMAGE} helm ls
    except:
      - master
  
  Test Docker:
    stage: test
    script:
      - docker pull ${CONTAINER_TEST_IMAGE}
      - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock ${CONTAINER_TEST_IMAGE} docker images
    except:
      - master
  
  release-image:
    stage: release
    script:
      - docker pull $CONTAINER_TEST_IMAGE
      - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
      - docker push $CONTAINER_RELEASE_IMAGE
    only:
      - master
  </code></pre>
  
  <p>Edit: Missed this part.. <strong>I'm using a shell runner.</strong></p>
  
  <p>So post of what I said is probably not relevant. How ever I do think there is some advantages to building and deploying with a gitlab runner directly on a cluster.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-16T15:24:04.107Z
Answers: 2018-04-16T15:36:18.943Z
Answers: 2018-04-16T15:36:18.943Z
Answers: Levi
Body: <p>I'm setting up a pipeline that compiles and builds new docker images, and then deploys those images to testing kubernetes cluster. </p>
  
  <p>I'm using a shell runner. </p>
  
  <p>I need to setup my <code>kubectl</code> client to point to the testing kubernetes cluster. (ie. setting the cluster and context).</p>
  
  <p>As I understand it - I should only need to run this once. Is there a way to get this to run once, as defined in the <code>.gitlab-ci.yaml</code>? Or should I just repeat the set up steps everytime in <code>before_script</code>? </p>
  
Comments: CC BY-SA 3.0
Comments: 2018-04-15T10:11:10.533Z
Comments: It widely depend on how you want to configure kubectl, I'd go with env vars and keep it in a before script, this would be idempotent and allow a move to containers later also
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2018-04-15T21:25:01.527Z
Comments: @dwjohnston what did you try? Please add the .gitlab-ci.yaml.
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-04-16T11:47:50.630Z
Comments: Why is defining it in the `before_script` not sufficient?
Comments: 030
Tags: <kubernetes><gitlab-ci-runner>
Title: One time/set up jobs on gitlab ci?
UserDisplayName: dwjohnston
ThreadText: # One time/set up jobs on gitlab ci?
  
  (Asked by: username_0 on 2018-04-11)
  
  I'm setting up a pipeline that compiles and builds new docker images, and then deploys those images to testing kubernetes cluster.
  
  I'm using a shell runner.
  
  I need to setup my `kubectl` client to point to the testing kubernetes cluster. (ie. setting the cluster and context).
  
  As I understand it - I should only need to run this once. Is there a way to get this to run once, as defined in the `.gitlab-ci.yaml`? Or should I just repeat the set up steps everytime in `before_script`?
  
  **Tags:** kubernetes, gitlab-ci-runner
  
  > **Comments:**
  > **username_1**: It widely depend on how you want to configure kubectl, I'd go with env vars and keep it in a before script, this would be idempotent and allow a move to containers later also  
  > **username_2**: @username_0 what did you try? Please add the .gitlab-ci.yaml.  
  > **username_2**: Why is defining it in the `before_script` not sufficient?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2018-04-16. Score: 3
  
  I dealt with the same issue. Some people recommended using the Gitlab group "secrets" and using `before_script`. Since I knew I was also going to deploy and would need other tools on my runner like "helm", I made my own docker container. I still keep my config for my clusters in a base64 encoded group secret but I set it like this in the dockerfile.
  
  ```
  ENV kube_config=$kube_config
  RUN echo -n ${kube_config} | base64 -d > ~/.kube/config
  
  ```
  
  Now just set an environment variable for your gitlab runner to point to your new image.
  
  ```
  KUBERNETES_IMAGE: registry.gitlab.com/MY_USERNAME/MY_REPO_NAME/MY_IMAGE_NAME:latest
  
  ```
  
  Don't forget to test your new container!
  
  ```
  stages:
    - build
    - test
    - release
  
  variables:
    CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE/gitlab_runner:$CI_COMMIT_REF_NAME
    CONTAINER_RELEASE_IMAGE: $CI_REGISTRY_IMAGE/gitlab_runner:latest
  
  before_script:
    - apt-get update && apt-get install docker.io -y
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  
  Build Image:
    stage: build
    script:
      - docker build --build-arg kube_config=${kube_config} -t ${CONTAINER_TEST_IMAGE} .
      - docker push ${CONTAINER_TEST_IMAGE}
    except:
      - master
  
  Test Kubectl:
    stage: test
    script:
      - docker pull ${CONTAINER_TEST_IMAGE}
      - docker run --rm ${CONTAINER_TEST_IMAGE} kubectl get deployments -n kube-system
    except:
      - master
  
  Test Helm:
    stage: test
    script:
      - docker pull ${CONTAINER_TEST_IMAGE}
      - docker run --rm ${CONTAINER_TEST_IMAGE} helm ls
    except:
      - master
  
  Test Docker:
    stage: test
    script:
      - docker pull ${CONTAINER_TEST_IMAGE}
      - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock ${CONTAINER_TEST_IMAGE} docker images
    except:
      - master
  
  release-image:
    stage: release
    script:
      - docker pull $CONTAINER_TEST_IMAGE
      - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
      - docker push $CONTAINER_RELEASE_IMAGE
    only:
      - master
  
  ```
  
  Edit: Missed this part.. **I'm using a shell runner.**
  
  So post of what I said is probably not relevant. How ever I do think there is some advantages to building and deploying with a gitlab runner directly on a cluster.
  
  
  ---
  
  