public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-13 01:36:23 +00:00
Code Issues Releases Wiki Activity

Two minor fixes in recipe "GitLab Runner" (#178)

Browse Source 
* gitlab-runner: Use a more succinct way to create directories

* gitlab-runner: Do not incorrectly mention "mail server"
This commit is contained in:
Frank 'Sigi' Luithle
2021-08-09 08:29:55 +02:00
committed by GitHub
parent 5e4465b2eb
commit 0f526442a6
1 changed files with 2 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
manuscript/recipes/gitlab-runner.md
View File

@@ -21,10 +21,7 @@ Existing:
We'll need several directories to bind-mount into our runner containers, so create them in `/var/data/gitlab`: We'll need several directories to bind-mount into our runner containers, so create them in `/var/data/gitlab`:
``` ```
cd /var/data mkdir -p /var/data/gitlab/runners/{1,2}
mkdir gitlab
cd gitlab
mkdir -p {runners/1,runners/2}
``` ```
### Setup Docker Swarm ### Setup Docker Swarm
@@ -88,9 +85,7 @@ check_interval = 0
### Launch runners ### Launch runners
Launch the mail server stack by running `docker stack deploy gitlab-runner -c <path -to-docker-compose.yml>` Launch the GitLab Runner stack by running `docker stack deploy gitlab-runner -c <path -to-docker-compose.yml>`
Log into your new instance at https://**YOUR-FQDN**, with user "root" and the password you specified in gitlab.env.
[^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. [^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. [^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.