qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] gitlab: always build container images


From: Thomas Huth
Subject: Re: [PATCH 1/3] gitlab: always build container images
Date: Tue, 9 Feb 2021 07:37:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 08/02/2021 17.33, Daniel P. Berrangé wrote:
[...]
For example, consider pushing 5 commits, one of which contains a
dockerfile change. This will trigger a CI pipeline for the
containers. Now consider you do some more work on the branch and push 3
further commits, so you now have a branch of 8 commits. For the second
push GitLab will only look at the 3 most recent commits, the other 5
were already present. Thus GitLab will not realize that the branch has
dockerfile changes that need to trigger the container build.

This can cause real world problems:

  - Push 5 commits to branch "foo", including a dockerfile change

     => rebuilds the container images with content from "foo"
     => build jobs runs against containers from "foo"

  - Refresh your master branch with latest upstream master

     => rebuilds the container images with content from "master"
     => build jobs runs against containers from "master"

  - Push 3 more commits to branch "foo", with no dockerfile change

     => no container rebuild triggers
     => build jobs runs against containers from "master"

The "changes" conditional in gitlab is OK, *provided* your build
jobs are not relying on any external state from previous builds.

This is NOT the case in QEMU, because we are building container
images and these are cached. This is a scenario in which the
"changes" conditional is not usuable.

The only other way to avoid this problem would be to use the git
branch name as the container image tag, instead of always using
"latest".
I'm basically fine with your patch, but let me ask one more thing: Won't we still have the problem if the user pushes to different branches simultaneously? E.g. the user pushes to "foo" with changes to dockerfiles, containers start to get rebuild, then pushes to master without waiting for the previous CI to finish, then the containers get rebuild from the "master" job without the local changes to the dockerfiles. Then in the "foo" CI pipelines the following jobs might run with the containers that have been built by the "master" job...

So if we really want to get it bulletproof, do we have to use the git branch name as the container image tag?

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]