From 0f526442a6b69bf22816768b7d802ef38c3534f1 Mon Sep 17 00:00:00 2001 From: Frank 'Sigi' Luithle Date: Mon, 9 Aug 2021 08:29:55 +0200 Subject: [PATCH] Two minor fixes in recipe "GitLab Runner" (#178) * gitlab-runner: Use a more succinct way to create directories * gitlab-runner: Do not incorrectly mention "mail server" --- manuscript/recipes/gitlab-runner.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/manuscript/recipes/gitlab-runner.md b/manuscript/recipes/gitlab-runner.md index 0498bd6..28dfefe 100644 --- a/manuscript/recipes/gitlab-runner.md +++ b/manuscript/recipes/gitlab-runner.md @@ -21,10 +21,7 @@ Existing: We'll need several directories to bind-mount into our runner containers, so create them in `/var/data/gitlab`: ``` -cd /var/data -mkdir gitlab -cd gitlab -mkdir -p {runners/1,runners/2} +mkdir -p /var/data/gitlab/runners/{1,2} ``` ### Setup Docker Swarm @@ -88,9 +85,7 @@ check_interval = 0 ### Launch runners -Launch the mail server stack by running `docker stack deploy gitlab-runner -c ` - -Log into your new instance at https://**YOUR-FQDN**, with user "root" and the password you specified in gitlab.env. +Launch the GitLab Runner stack by running `docker stack deploy gitlab-runner -c ` [^1]: You'll note that I setup 2 runners. One is locked to a single project (_this cookbook build_), and the other is a shared runner. I wanted to ensure that one runner was always available to run CI for this project, even if I'd tied up another runner on something heavy-duty, like a container build. Customize this to your use case. [^2]: Originally I deployed runners in the same stack as GitLab, but I found that they would frequently fail to start properly when I launched the stack. I think that this was because the runners started so quickly (_and GitLab starts **sooo** slowly!_), that they always started up reporting that the GitLab instance was invalid or unavailable. I had issues with CI builds stuck permanently in a "pending" state, which were only resolved by restarting the runner. Having the runners deployed in a separate stack to GitLab avoids this problem.