GitLab CI 构建多个 docker + 端到端测试

Question

I want to build and test multiple dockers from one repo in GitLab. This monorepo holds a few microservices that work together.
We have have a working docker compose up to aid local dev, so thats a start. Goal is move build + test to GitLab, run a E2E test (end-to-end) of these dockers, and let GitLab upgrade our staging environment.

The building of multiple dockers is just multiple jobs in build stage of the (one) pipeline, testing can happen per docker i guess, which leaves testing the whole with multiple dockers running in a (or the?) staging environment.

1. How can GitLab run E2E tests on multiple dockers? (or is this unwise to begin with)

2. Would we need Kubernetes for the inter-docker mapping (network, volumes, but also dependencies) that docker-compose now facilitates?

We are using a self-hosted GitLab CE instance.

Update: cut shorter, use proper terminology.

Answer 1

I haven't worked on PHP, and never done Docker build for multi module, although I tried out a quick example of multi module kind of thing for Nodejs. Check this Repo

Refer to .gitlab-ci.yml which builds two independent hello world kind of nodejs module.

I now adapted this to build docker images separately.

Original answer (question changed 12th July)

You haven't mentioned what documentation you are referring to. You should be able to configure using .gitlab-ci.yml

AFAIK Building docker image should be programming language agnostic. If you can run docker build . on your local. Following documentation should help https://docs.gitlab.com/ee/ci/docker/using_docker_build.html

You can use Gitlab pipeline for testing < - > building images. Refer to https://docs.gitlab.com/ee/ci/pipelines.html

Refer to this for PHP build - https://docs.gitlab.com/ee/ci/examples/php.html

Answer 2

Answering my own question, 2 years of experience later.

• For a normal (single-project/service) repo the CI is straightforward.
• For a monorepo, an end-to-end test is straightforward.

You can combine these aspects by having a repo with submodules, its essentially both. But this can cause overhead if done continiously and mostly usefull for proofing beta/alpha and release-candidates.

If you know more options, feel free to add here.