[choeger]

How and when would that push/pull work?

Here is the typical use case. Dev A wants to upgrade a dependency, say the boost library for a C++ project. This requires some adaption. So they create a changeset/pull request. Inside that pull request they adapt the Dockerfile to use the latest boost library version.

The same day, developer B finishes a story and uses some legacy boost features. They also submit a pull request. That change does not build with the newer library but works fine with the older one.

The CI system now should be able to run the tests with both changesets independently, using the Dockerfile from each branch.

When B's work is merged first, A needs to rebase and vice-versa.

Right now we implement this by running CI outside docker and creating and entering a container with a script provided by the project, but that is a home-grown solution. I would love to see gitlab allow each branch to create its container automatically, when needed.

[e12e]

I'm not sure I follow, typical gitlab ci runs in the branch? So there's eg a .gitlab-ci.yml and a ./Dockerfile in branch "new-feature", and one in "old-story".

They would both run OK in your scenario. If "new-feature" is merged first, "old-branch" would have to merge with (new) master and fix ci before being able to pass ci and be allowedtto merge?

[choeger]

Usually you annotate the CI file with a container ID, not a Dockerfile, AFAIK.

[piaste]

You can use the Gitlab CI variables so that both the "docker build" job and the "test docker image" job use a unique image ID for your pull request.

Personally I use branch + git tag name as the image tag, but you can use a commit hash or whatever.

[e12e]

Hm, ok. We build containers using ci, but I see how you might want to have a container for running tests. Depends a bit on the language/framework i suppose.