qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v5 4/4] Jobs based on custom runners: add job definitions for


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v5 4/4] Jobs based on custom runners: add job definitions for QEMU's machines
Date: Tue, 23 Feb 2021 17:41:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 2/23/21 4:56 PM, Daniel P. Berrangé wrote:
> On Tue, Feb 23, 2021 at 04:17:23PM +0100, Philippe Mathieu-Daudé wrote:
>> On 2/19/21 10:58 PM, Cleber Rosa wrote:
>>> The QEMU project has two machines (aarch64 and s390x) that can be used
>>> for jobs that do build and run tests.  This introduces those jobs,
>>> which are a mapping of custom scripts used for the same purpose.
>>>
>>> Signed-off-by: Cleber Rosa <crosa@redhat.com>
>>> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>>> ---
>>>  .gitlab-ci.d/custom-runners.yml | 204 ++++++++++++++++++++++++++++++++
>>>  1 file changed, 204 insertions(+)
>>>
>>> diff --git a/.gitlab-ci.d/custom-runners.yml 
>>> b/.gitlab-ci.d/custom-runners.yml
>>> index 3004da2bda..a9166c82a2 100644
>>> --- a/.gitlab-ci.d/custom-runners.yml
>>> +++ b/.gitlab-ci.d/custom-runners.yml
>>> @@ -12,3 +12,207 @@
>>>  # strategy.
>>>  variables:
>>>    GIT_SUBMODULE_STRATEGY: recursive
>>> +
>>> +# All ubuntu-18.04 jobs should run successfully in an environment
>>> +# setup by the scripts/ci/setup/build-environment.yml task
>>> +# "Install basic packages to build QEMU on Ubuntu 18.04/20.04"
>>> +ubuntu-18.04-s390x-all-linux-static:
>>> + allow_failure: true
>>> + needs: []
>>> + stage: build
>>> + tags:
>>> + - ubuntu_18.04
>>> + - s390x
>>
>> Where is this tag list filled upon registration?
>>
>>> + rules:
>>> + - if: '$CI_COMMIT_BRANCH =~ /^staging/'
>>> + script:
>>> + # --disable-libssh is needed because of 
>>> https://bugs.launchpad.net/qemu/+bug/1838763
>>> + # --disable-glusterfs is needed because there's no static version of 
>>> those libs in distro supplied packages
>>> + - mkdir build
>>> + - cd build
>>> + - ../configure --enable-debug --static --disable-system 
>>> --disable-glusterfs --disable-libssh
>>> + - make --output-sync -j`nproc`
>>> + - make --output-sync -j`nproc` check V=1
>>> + - make --output-sync -j`nproc` check-tcg V=1
>>
>> Also this break the rest of the tests...
>>
>> The first containers job (amd64-alpine-container) got
>> added to the custom runner and failed (because docker-dind
>> isn't there?):
> 
> Urgh, well that's a big problem. We certainly don't want *anything* being
> placed on the custom runners without explicit opt-in, otherwise jobs run
> in the main repo have a different environment from when users run on their
> personal forks.
> 
> IOW, we need anti-affinity against our custom runners really.
> 
>> $ export TAG="$CI_REGISTRY_IMAGE/qemu/$NAME:latest"
>> $ export COMMON_TAG="$CI_REGISTRY/qemu-project/qemu/$NAME:latest"
>> $ apk add python3
>> bash: line 110: apk: command not found
>> Running after_script 00:01
>> Running after script...
>> $ docker logout
>> Removing login credentials for https://index.docker.io/v1/
>> ERROR: Job failed: exit status 1
>>
>> Do we need to restrict the other jobs to the Gitlab public
>> (x86) runners? Maybe as:
>>
>> diff --git a/.gitlab-ci.d/containers.yml b/.gitlab-ci.d/containers.yml
>> @@ -1,6 +1,6 @@
>>  .container_job_template: &container_job_definition
>> +  tags:
>> +    - gitlab-org-docker
> 
> Is that a real tag that exists on gitlab's shared runners, or something
> you just invented ?

This is not standardized yet:
https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/5420

I checked the available runners, some have 'docker' while other have
'gitlab-org-docker'. There are more 'gitlab-org-docker' than 'docker'
runners. The tag selection is not exclusive, this is a "all or nothing"
selection, so for my testing I choose 'gitlab-org-docker' which is
the most available.

> 
>>    image: docker:stable
>>    stage: containers
>>    services:
>>
>> Daniel, you didn't hit this problem on the previous version
>> of this series?
> 
> I didn't try actually executing previous postings of this series.
> 
> 
> Regards,
> Daniel
> 




reply via email to

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