[2/3] Update .gitlab-ci.yml

Submitted by Snir Sheriber on Feb. 25, 2019, 2:56 p.m.

Details

Message ID 20190225145647.31675-3-ssheribe@redhat.com
State New
Headers show
Series "Integration with copr build system" ( rev: 1 ) in Spice

Not browsing as part of any series.

Commit Message

Snir Sheriber Feb. 25, 2019, 2:56 p.m.
---
 .gitlab-ci.yml | 1 -
 1 file changed, 1 deletion(-)

Patch hide | download patch | download mbox

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
 

Comments

> 
> ---
>  .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.
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.

I don't know much about how the current copr build are set.
Who set them? Where are the scripts that generate them?
Isn't fedpkg using mock to build? Then why installing
spice-protocol on the machine?

Frediano
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)


> 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)


>
> 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


> 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 tried to add the copr as a repo but it didn't let me so i just 
installed spice-protocol from git.


Snir.

>
> Frediano
> 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?

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

> 
> > 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)

> 
> > 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
>
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