From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
qemu-devel@nongnu.org,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>
Subject: Re: [PATCH] gitlab-ci: Only push Docker 'latest' image when building default branch
Date: Tue, 16 Feb 2021 11:37:08 +0100 [thread overview]
Message-ID: <3d817033-2a28-9ed8-5712-c5d7a53b76db@redhat.com> (raw)
In-Reply-To: <YCuV624Qhy5F9CAZ@redhat.com>
On 2/16/21 10:52 AM, Daniel P. Berrangé wrote:
> On Tue, Feb 16, 2021 at 08:05:09AM +0100, Philippe Mathieu-Daudé wrote:
>> On 2/16/21 7:55 AM, Thomas Huth wrote:
>>> On 15/02/2021 20.28, Philippe Mathieu-Daudé wrote:
>>>> While we are interested in building docker images in different
>>>> branches, it only makes sense to push 'latest' to the registry
>>>> when this is the project default branch (usually 'master').
>>>>
>>>> Else when pushing different branches concurrently we might have
>>>> inconsistent image state between branches.
>>>>
>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>> ---
>>>> .gitlab-ci.d/containers.yml | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/.gitlab-ci.d/containers.yml b/.gitlab-ci.d/containers.yml
>>>> index 90fac85ce46..52a915f4141 100644
>>>> --- a/.gitlab-ci.d/containers.yml
>>>> +++ b/.gitlab-ci.d/containers.yml
>>>> @@ -17,7 +17,7 @@
>>>> -t "qemu/$NAME" -f "tests/docker/dockerfiles/$NAME.docker"
>>>> -r $CI_REGISTRY_IMAGE
>>>> - docker tag "qemu/$NAME" "$TAG"
>>>> - - docker push "$TAG"
>>>> + - test "$CI_COMMIT_BRANCH" = "$CI_DEFAULT_BRANCH" && docker push
>>>> "$TAG"
>>>
>>> So does that mean that the following stages in the CI (i.e. build, test)
>>> are only always (i.e. also for the non-master branches) going to use
>>> containers that have been build on the master branch?
>>
>> Hmm good point. Should we use "$CI_COMMIT_BRANCH" instead of "latest"?
>
> This doesn't work because git branch names are not guaranteed to be
> valid docker tag names. Please see my thread here:
>
> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg03535.html
Indeed this thread describes the problem I am having. I'll see if there
are follow up on your thread.
Another way of fixing this is to find a way to only allow 1 pipeline at
a time. I haven't tried it yet because I don't like the idea of making
CI slower, but this is still better than debugging inconsistent
pipelines when Docker images are rebuilt.
Regards,
Phil.
prev parent reply other threads:[~2021-02-16 10:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-15 19:28 [PATCH] gitlab-ci: Only push Docker 'latest' image when building default branch Philippe Mathieu-Daudé
2021-02-16 6:55 ` Thomas Huth
2021-02-16 7:05 ` Philippe Mathieu-Daudé
2021-02-16 9:52 ` Daniel P. Berrangé
2021-02-16 10:37 ` Philippe Mathieu-Daudé [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d817033-2a28-9ed8-5712-c5d7a53b76db@redhat.com \
--to=philmd@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).