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

CC BY-SA 3.0
2018-04-16T15:24:04.107Z
2018-04-16T15:36:18.943Z
2018-04-16T15:36:18.943Z
Levi
<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>

CC BY-SA 3.0
2018-04-15T10:11:10.533Z
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
Tensibai
CC BY-SA 3.0
2018-04-15T21:25:01.527Z
@dwjohnston what did you try? Please add the .gitlab-ci.yaml.
030
CC BY-SA 3.0
2018-04-16T11:47:50.630Z
Why is defining it in the `before_script` not sufficient?
030
<kubernetes><gitlab-ci-runner>
One time/set up jobs on gitlab ci?
dwjohnston
# 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.


---

