Hacker News Reader

Comment by choeger | Hacker News Reader

Thanks for open sourcing your work.

Question: is it possible to describe the build environment inside a project with your approach? Bonus question: Is it possible to generate the build environment within a project? Because this is a totally missing feature for me, to the point I might add it one day to gitlab or Jenkins. As a developer, you should not be forced to repeat yourself in any way. And you should be able to replicate your build everywhere, including your local machine. Hence I consider it important to put the dockerfiles, etc. Inside the repo. I would be fine with having a script that generates the Jenkins pipeline, gitlab ci, or whatever on demand, but I do not want to keep the same information in sync everywhere.

View on HN

GitLab engineer here, I'm curious what you're thinking of exactly. Right now you could commit your Dockerfile, use it in CI to generate an image, and push it to the registry where you can pull it from. Do you mean some convenience features to automate these steps without requiring an explicit CI setup?

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.

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?

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

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.

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.

Reply on news.ycombinator.com