I have an Ultimate subscription in GitLab.com
I always use shared runners but recently I had a scenario where I need to run integration tests (from a .NET app) against a MongoDb replica set as part of the CI/CD pipeline.
Replica sets in MongoDb are complex to setup, so I decided to create my own Docker image which run, in the same container, 3 nodes of MongoDb initiated as a replica set.
I’ve created a copy here: Sunny Attic Software / sandbox / mongo-rs · GitLab
Then I have created another repository with a tiny .NET app and an automated test, simply to test connectivity with this mongo-rs custom container. It has further instructions on how to use it.
Sunny Attic Software / sandbox / mongo-rs-tester-dotnet · GitLab
In localhost it works well when I spin up the container with a simple docker-compose
version: '3.8' services: mongors: image: registry.gitlab.com/sunnyatticsoftware/sandbox/mongo-rs container_name: mongors environment: HOST: mongors DELAY_INITIATE: 40 ports: - 27017:27017 - 27018:27018 - 27019:27019
And then I run my tester with a simple
dotnet test assuming I have the .NET 7 SDK and Docker installed.
So now I wanted to run it in my GitLab.com CI/CD pipeline with shared built-in runners, and, for some reason, the tests always fail due to the mongo-rs service not being properly initiated. I suspect it has something to do with how GitLab CI/CD runners configure the network, and the nodes not seeing each other through the alias.
This is the
.gitlab-ci.yml which should be equivalent
image: mcr.microsoft.com/dotnet/sdk:7.0 stages: - test test: stage: test services: - name: registry.gitlab.com/sunnyatticsoftware/sandbox/mongo-rs alias: mongors variables: HOST: "mongors" DELAY_INITIATE: "40" before_script: - sleep 30 script: - dotnet test allow_failure: false
The interesting thing is that if I disable the shared runners for the project, and I create one using Linux and docker and then I grab the token and register one in my Ubuntu 22.04 WSL2
sudo gitlab-runner register Runtime platform arch=amd64 os=linux pid=2237 revision=79704081 version=16.0.1 Running in system-mode. Enter the GitLab instance URL (for example, https://gitlab.com/): https://gitlab.com/ Enter the registration token: glrt-************** Verifying runner... is valid runner=RLN7LzqzE Enter a name for the runner. This is stored only in the local config.toml file: [RBKL-025]: sasw-runner Enter an executor: virtualbox, docker-autoscaler, docker+machine, instance, custom, docker, parallels, shell, kubernetes, docker-windows, ssh: docker Enter the default Docker image (for example, ruby:2.7): mcr.microsoft.com/dotnet/sdk:7.0 Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
and I run the CI/CD pipeline, it succeeds!
I don’t really understand what’s the difference.
After enabling shared runners again I have tried adding tags
docker and also
linux to my
.gitlab-ci.yml job hoping that it would pick a shared runner with same characteristics as when I use my registered one, but no luck. It fails.
Is there any way to have my CI/CD pipeline behave similarly to my localhost (whether linux WSL2 or Windows) or my custom runner?
Using my own runner is not really an option, as I want to use the GitLab.com SaaS and I don’t want to have a local runner available to run CI/CD pipelines and want to use shared ones.
I created a Stackoverflow question here