[Spice-devel] [PATCH 2/3] Update .gitlab-ci.yml

[Snir Sheriber]

On 2/26/19 4:41 PM, Frediano Ziglio wrote:
>> Hi,
>>
>> On 2/26/19 11:26 AM, Frediano Ziglio wrote:
>>>> ---
>>>>    .gitlab-ci.yml | 1 -
>>>>    1 file changed, 1 deletion(-)
>>>>
>>>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>>>> index ab1b2a3..57d3dd9 100644
>>>> --- a/.gitlab-ci.yml
>>>> +++ b/.gitlab-ci.yml
>>>> @@ -3,7 +3,6 @@ image: fedora:latest
>>>>    before_script:
>>>>        - >
>>>>          dnf install -y 'dnf-command(copr)' make automake autoconf
>>>>          autoconf-archive libtool xz gcc-c++
>>>> -      libdrm-devel libXrandr-devel
>>>>        - dnf copr enable @spice/nightly -y
>>>>        - dnf builddep spice-streaming-agent -y
>>>>    
>>> Considering patch 3/3 also gcc-c++ should be removed.
>>
>> Well, this will be true if patch 1/3 is in too, since currently the
>> builds are created
>> from another spec file (which I'll update manually so it will work)
>>
> In this case it's really twisted!
> 1- Gitlab uses dnf builddep from spice-streaming-agent nigthly;
> 2- dnf builddep from spice-streaming-agent nigthly uses the SPEC inside
>     spice-streaming-agent @copr;
> 3- spice-streaming-agent is generated by copr from SRPM;
> 4- SRPM is generated from Gitlab from SPEC + TARBALL;
> 5- this last SPEC is generated from Gitlab using dependencies
>     from SPEC.IN.
>
> So why at step 1 not using the same dependencies at step 5?


It's the same dependencies but indirectly.

But you are right .gitlab-ci.yml can probably get its dependencies also
from the spec file (hopefully spec.in can be accessed from before_script)


>
> Conceptually the CI should try to use step similar to what an
> user or developer does. I honestly never used @copr to build
> spice.

I'm not sure if copr is really considered ci but i find it useful
to get easily upstream spice components in vms without compiling
anything.


>
>>> Also looks like the tendency is to remove the dependency from
>>> @spice/nightly. Considering also 1/3 looks like we are creating
>>> a circular dependency where copr build is launched by Gitlab and
>>> Gitlab build depends on copr build.
>> Indeed, at first i thought to specify the deps and clone spice-protocol
>> as was done
>> on other projects, but considering the creation of the nightly builds
>> directly using
>> the spec file which is inside the repo, keeping the builddep will reduce
>> the number
>> of changes need to be done when a new dependency is added.
>>
>> No builddep- spec file + .gitlab-ci.yml require an update.
>>
>> With builddep- just update spec, copr build will be created immediately
>> with this
>> change so builddep will follow (although !first! gitlab ci run may fail
>> if it builds
>> faster than copr)
>>
> Another issue which happened multiple times is that copr can be down
> or having issues which will make Gitlab CI fail.
>
>>> I don't know much about how the current copr build are set.
>>> Who set them? Where are the scripts that generate them?
>>
>> Current state is that a vm with cron job is checking for updates every
>> few hours
>> The scripts were mostly done by Pavel an mostly located in
>> https://gitlab.com/sheriber/copr-build-helper (i need to push recent
>> changes)
>>
>> Moving to gitlab to generate the builds would make it easier to follow
>> and maintain
>>
> It would be good if it was possible to do
> - make dist
> - rpmbuild -ts *.tar.xz
> - mock *.src.rpm
> (maybe with a manual build & install of spice-protocol)

I do not get the difference, this is kind of what happens now, once
the src.rpm is generated it is being rebuilt in several different fresh
releases (&architectures) which has the nightly-builds as a repo (so
spice-protocol is the latest upstream too)


Snir

>
>>> Isn't fedpkg using mock to build? Then why installing
>>> spice-protocol on the machine?
>> No, it builds on the machine itself, actually release may not be needed.
>> I think rpmbuild –bs will be equal (even better maybe)
>>
> I think in copr it works because spice-protocol is a nightly too.
>
>> I tried to add the copr as a repo but it didn't let me so i just
>> installed spice-protocol from git.
>>
>>
>> Snir.
>>
>>> Frediano