skip to Main Content

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


  1. You can manipulate the entrypoint of the services like this:

      services:
        - name: service
          entrypoint:
            - '/bin/sh'
            - '-c'
            - |
              echo 'some waiting script'
              echo 'call real entrypoint here'

    Then you can use a ‘wait-for-it’ logic and afterwards start the real entrypoint.

    Login or Signup to reply.
  2. 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 the script: section entirely.

    For example, if you have an approach using docker-compose that works, consider just invoking docker-compose in your job script:.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search