Try to load the InCluster config first, if that fails load kubectl config
What does this MR do?
Allows Kubernetes executor to use the in-cluster service account.
Why was this MR needed?
Are there points in the code the reviewer needs to double check?
Does this MR meet the acceptance criteria?
-
Documentation created/updated - Tests
-
Added for this feature/bug -
All builds are passing
-
-
Branch has no merge conflicts with master
(if you do - rebase it please)
What are the relevant issue numbers?
Merge request reports
Activity
Mentioned in merge request !326 (closed)
@nick.thomas @ayufan without this change our docs on the k8s executor contradict it's behaviour - I'm not sure how release cycles work for the runner, but can this be put into the next minor release? hopes we don't have to wait until 22nd October
@tmaczukin Should we put that in patch?
Mentioned in merge request !331 (closed)
@tmaczukin ? :)
Mentioned in merge request !338 (closed)
I have build this branch, but I get the error:
Missing /usr/bin/gitlab-runner-helper. Uploading artifacts is disabled.
@waterfoul Clone the repository, Checkout the branch, then run
docker build .
in the repository root.@tmaczukin @ayufan can this get merged in? Without this PR we contradict ourselves in the documentation. The current recommended setup for the Kubernetes executor is invalid and doesn't work. This MR fixes that.
Seems quite a few people are running into this issue now, and having to build a custom image in order to follow recommended setup is (obviously) wrong
@pvanderlinden that message you receive is expected - follow !338 (closed) for updates on adding a helper-container that's responsible for artefacts/caching/git cloning.
@munnerz Does that mean that the k8s executor does not support artifacts at all yet?
They are supported, however it requires a
gitlab-runner-helper
binary to be placed at/usr/bin/gitlab-runner-helper
- I'm aware this is extremely inconvenient, and potentially a show stopper for many (myself included, I have a custom build that I use myself).It was decided to be this way until a proper way of versioning a docker image for the
gitlab-runner-helper
can be decided. !338 (closed) adds support for running an externally hosted helper image within each pod, and !275 (closed) adds support for pushing a Docker image for the helper to Dockerhub.If at all helpful, I have a copy of the image for the helper built here: https://hub.docker.com/r/munnerz/gitlab-runner-helper/ I've also got a custom build of the gitlab-runner built here: munnerz/gitlab-ci-multi-runner - I'd recommend using the :asap tag, as that's the one I'm currently using and is most up to date. Neither of these two images are supported by GitLab, and both come with absolutely no warranty! (but my workplace, and myself personally, as well as quite a few others are running it fine). It's built from my own fork, on the k8s-asap branch.
Edited by James Munnelly@waterfoul Clone the repository, Checkout the branch, then run
docker build .
in the repository root.This way you will build the
:develop
version of the image, which is not prepared to be used as aproduction
one. Please go to thedockerfiles
- thealpine
andubuntu
directories contains Dockerfiles forgitlab/gitlab-runner
image.@munnerz I'm looking on the MR right now.
Mentioned in commit 75c65d8d
Mentioned in issue #1759 (closed)