I have a Gitlab-CI
job with multiple services needed to run integration tests :
variables:
FF_NETWORK_PER_BUILD: 'true' # Create a network for all services of a build
my-test-job:
services:
- name: myservice-a:1.0.0
alias: serva
- name: myservice-b:1.0.0
alias: servb
The service B needs the service A to be up and running to work. If service A is not available when service B starts, the service B crashes.
On Kubernetes
or docker-compose
it’s not a problem because of built-in retry mechanism. With Gitlab-CI
services there is no retry mechanism according to the documentation, so I’m wondering how I can avoid race conditions issues in this case ?
Moreover, I can’t use docker-compose
on Gitlab-CI
, because I need to use shared runners from my company without root access.
I could probably use a wait-for-it solution but I would prefer not to modify the images if possible.
2
Answers
You can manipulate the entrypoint of the services like this:
Then you can use a ‘wait-for-it’ logic and afterwards start the real entrypoint.
You can’t. The restart policy for services is not user-configurable.
Besides making your own entrypoint as Kerrim suggested (see also: additional reference), if you can’t configure service B to use retries in its startup logic, you should just avoid using
services:
for this use case altogether and orchestrate your testing within thescript:
section entirely.For example, if you have an approach using
docker-compose
that works, consider just invokingdocker-compose
in your jobscript:
.