Re: [PATCH 2/3] Update .gitlab-ci.yml

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

 



> 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
> 
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux Virtualization]     [Linux Virtualization]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]