<p>I am considering porting a legacy pipeline that builds and tests Docker/OCI images into GitLab CI/CD. I already have a GitLab Runner in a Kubernetes cluster and it's registered to a GitLab instance. Testing a particular image requires running certain commands inside (for running unit tests, etc.). Presumably this could be modeled by a job <code>my_test</code> like so:</p>
<pre><code>my_test:
  stage: test
  image: my_image_1
  script:
  - my_script.sh
</code></pre>
<p>However, these tests are not completely self-contained but also require the presence of a second container (a database, i.e.). At the outset, I can imagine one, perhaps suboptimal way for handling this (there would also have to be some logic for waiting until <code>my_image2</code> has started up and a way for <code>kubectl</code> to obtain sufficient credentials):</p>
<pre><code>  before_script: kubectl deployment create my_deployment2 ...
  after_script: kubectl delete deployment my_deployment2 ...
</code></pre>
<p>I am fairly new to GitLab CI/CD so I am wondering: What is best practice for modeling a test like this one, i.e. situations where tests requires orchestration of multiple containers? (Does this fit into the scope of a GitLab job or should it better be delegated to other software that <code>my_test</code> could talk to?)</p>

rookie099
<p>Your first look should be at <a href="https://docs.gitlab.com/ee/ci/services/" rel="nofollow noreferrer">Services</a>.</p>
<p>With services you can start a container running <code>MySQL</code> or <code>Postgres</code> and run tests which will connect to it.</p>
