[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Could we enable Travis-CI on our github mirrors?
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2016-04-21 7:48:43
Message-ID: CA+XidOECYq+wVd6OxS-UpNzkQhEV9ULWsEp+nLS2pj_-AR-Pog () mail ! gmail ! com
[Download RAW message or body]

On Thu, Apr 21, 2016 at 7:41 PM, Elvis Angelaccio
<elvis.angelaccio@kdemail.net> wrote:
>
>
> 2016-04-21 3:07 GMT+02:00 Ben Cooksley <bcooksley@kde.org>:
>>
>> On Thu, Apr 21, 2016 at 10:07 AM, Elvis Angelaccio
>> <elvis.angelaccio@kdemail.net> wrote:
>> >
>> >
>> > 2016-04-20 23:20 GMT+02:00 Albert Astals Cid <aacid@kde.org>:
>> >>
>> >> El dimecres, 20 d'abril de 2016, a les 23:00:26 CEST, Elvis Angelaccio
>> >> va
>> >> escriure:
>> >> > 2016-04-20 22:09 GMT+02:00 Albert Astals Cid <aacid@kde.org>:
>> >> > > El dimecres, 20 d'abril de 2016, a les 18:42:31 CEST, Elvis
>> >> > > Angelaccio
>> >> > > va
>> >> > >
>> >> > > escriure:
>> >> > > > Hi,
>> >> > > > as many of you already know, KDE has a github mirror in place at
>> >> > > > [1].
>> >> > > > I've been playing with travis-ci [2] and I was surprised by how
>> >> > > > easy
>> >> > > > to
>> >> > >
>> >> > > use
>> >> > >
>> >> > > > and how well integrated with github is.
>> >> > > >
>> >> > > > I think it would be nice to have travis builds for the (mirrored)
>> >> > > > repositories that provides a .travis.yml configuration file. The
>> >> > > > builds
>> >> > > > would run on the travis servers, so no additional overload on the
>> >> > > > KDE
>> >> > > > infrastructure. There is also virtually nothing to do for KDE
>> >> > > > sysadmins.
>> >> > > > The project's maintainer is the one in charge to setup the travis
>> >> > > > configuration file (if he wants to), in order to have working
>> >> > > > builds.
>> >> > > >
>> >> > > > Would this be possible from a technical p.o.v.? I think the KDE
>> >> > > > github
>> >> > > > account would have to register on the travis website and "sync"
>> >> > > > its
>> >> > >
>> >> > > github
>> >> > >
>> >> > > > repositories - that's what I had to do with my personal github
>> >> > > > account.
>> >> > > >
>> >> > > > The use cases could be many. For example, on travis I can install
>> >> > >
>> >> > > optional
>> >> > >
>> >> > > > dependencies that are not available on our Jenkins installation.
>> >> > > > More
>> >> > > > details in this post [3].
>> >> > > >
>> >> > > >
>> >> > > > What do you think?
>> >> > >
>> >> > > I don't see the point in having two CI systems, just help improve
>> >> > > the
>> >> > > one
>> >> > > we
>> >> > > have.
>> >> > >
>> >> > > If you need dependencies, why did you start a new CI system instead
>> >> > > of
>> >> > > asking
>> >> > > for the dependendies to be installed?
>> >> >
>> >> > Well I did ask, but those deps are not available in the Ubuntu
>> >> > repositories
>> >> > currently used by Jenkins.
>> >> > Maybe a solution could be to install them from source/manually, but
>> >> > that
>> >> > requires work from the sysadmins, who have already enough in their
>> >> > plate.
>> >>
>> >> I see. Maybe you can offer to help them?
>> >
>> >
>> > Not sure I have enough skills (especially now that we use docker), but I
>> > can
>> > ceirtainly try. Should I contact Ben?
>>
>> Docker shouldn't complicate things too much - it's essentially an
>> enhanced chroot.
>> If you're considering depending on this, have you spoken with the
>> Kubuntu packagers regarding getting this (hopefully non-Qt dependent)
>> dependency packaged?
>>
>> If it's Qt based, I do hope it isn't using QMake.
>
>
> They are not Qt based. In Ark we have (optional) tests that relies on
> packages such as unrar/rar and unarchiver. Both seems not packaged in the
> ubuntu version used by Jenkins.
> I'm fine with running these tests only locally on my system, but if there is
> something I can do to have them in our CI would be super-awesome.

We run Ubuntu Wily as our base. Have you checked to see whether 16.04
will contain these utilities?
I suspect unrar/rar will be missing due to it's proprietary nature.

Cheers,
Ben

>
>>
>>
>> Regards,
>> Ben
>>
>> >
>> >>
>> >>
>> >> > I did not start a new CI, I was basically playing with travis for
>> >> > fun.
>> >> > But
>> >> > then it turned out that it could solve an issue I have. The travis
>> >> > infrastrucure is already there, why not use it if one or more
>> >> > projects
>> >> > could benefit? Seems a win-win to me.
>> >>
>> >> As a release team member i won't look at the github CI
>> >>
>> >> I will look at our official one, but you will look at the github one
>> >> since
>> >> for
>> >> you "it's better"
>> >
>> >
>> > I never said it's better. I think it would be a nice addition, doesn't
>> > mean
>> > that I would stop looking at our main CI
>> >
>> >>
>> >>
>> >> I can see this creating problems, like for example build.kde.org
>> >> passing
>> >> and
>> >> githubCI not passing and you getting mad at me because we released
>> >> something
>> >> that doesn't work.
>> >
>> >
>> > This is a fair point, but see also my previous reply to Luca (the "who
>> > cares" part).
>> > I can promise you that I won't get mad at you, fwiw :)
>> >
>> >>
>> >>
>> >> Cheers,
>> >>   Albert
>> >>
>> >> >
>> >> > > Cheers,
>> >> > >
>> >> > >   Albert
>> >> >
>> >> > Cheers,
>> >> > Elvis
>> >> >
>> >> > > > Regards,
>> >> > > > Elvis
>> >> > > >
>> >> > > >
>> >> > > > [1]: https://github.com/KDE
>> >> > > > [2]: https://travis-ci.org/
>> >> > >
>> >> > > > [3]:
>> >> > >
>> >> > >
>> >> > > http://www.aelog.org/travis-ci-builds-of-kde-projects-on-archlinux-chroot/
>> >>
>> >>
>> >
>
>
[prev in list] [next in list] [prev in thread] [next in thread]