[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: Elvis Angelaccio <elvis.angelaccio () kdemail ! net>
Date: 2016-04-21 8:01:25
Message-ID: CALN1cnumnLCNr7Ka92dqu36q8idzOx4jw7OFyJgzidEGs81Q9w () mail ! gmail ! com
[Download RAW message or body]
2016-04-21 9:48 GMT+02:00 Ben Cooksley <bcooksley@kde.org>:
> 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.
>
This is correct. That's why we introduced a plugin for unarchiver in the
first place.
Yet it looks like they are both available in wily, respectively in the
multiverse [1][2] and universe [3] repos.
Would be possible to have at least [3]?
[1]: http://packages.ubuntu.com/wily/unar
[2]: http://packages.ubuntu.com/wily/rar
[3]: http://packages.ubuntu.com/wily/unar
>
> 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/
> >> >>
> >> >>
> >> >
> >
> >
>
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-04-21 \
9:48 GMT+02:00 Ben Cooksley <span dir="ltr"><<a href="mailto:bcooksley@kde.org" \
target="_blank">bcooksley@kde.org</a>></span>:<br><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Thu, Apr 21, 2016 \
at 7:41 PM, Elvis Angelaccio<br> <<a \
href="mailto:elvis.angelaccio@kdemail.net">elvis.angelaccio@kdemail.net</a>> \
wrote:<br> ><br>
><br>
> 2016-04-21 3:07 GMT+02:00 Ben Cooksley <<a \
href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>>:<br> >><br>
>> On Thu, Apr 21, 2016 at 10:07 AM, Elvis Angelaccio<br>
>> <<a href="mailto:elvis.angelaccio@kdemail.net">elvis.angelaccio@kdemail.net</a>> \
wrote:<br> >> ><br>
>> ><br>
>> > 2016-04-20 23:20 GMT+02:00 Albert Astals Cid <<a \
href="mailto:aacid@kde.org">aacid@kde.org</a>>:<br> >> >><br>
>> >> El dimecres, 20 d'abril de 2016, a les 23:00:26 CEST, Elvis \
Angelaccio<br> >> >> va<br>
>> >> escriure:<br>
>> >> > 2016-04-20 22:09 GMT+02:00 Albert Astals Cid <<a \
href="mailto:aacid@kde.org">aacid@kde.org</a>>:<br> >> >> > > El \
dimecres, 20 d'abril de 2016, a les 18:42:31 CEST, Elvis<br> >> >> > \
> Angelaccio<br> >> >> > > va<br>
>> >> > ><br>
>> >> > > escriure:<br>
>> >> > > > Hi,<br>
>> >> > > > as many of you already know, KDE has a github mirror \
in place at<br> >> >> > > > [1].<br>
>> >> > > > I've been playing with travis-ci [2] and I was \
surprised by how<br> >> >> > > > easy<br>
>> >> > > > to<br>
>> >> > ><br>
>> >> > > use<br>
>> >> > ><br>
>> >> > > > and how well integrated with github is.<br>
>> >> > > ><br>
>> >> > > > I think it would be nice to have travis builds for \
the (mirrored)<br> >> >> > > > repositories that provides a \
.travis.yml configuration file. The<br> >> >> > > > builds<br>
>> >> > > > would run on the travis servers, so no additional \
overload on the<br> >> >> > > > KDE<br>
>> >> > > > infrastructure. There is also virtually nothing to \
do for KDE<br> >> >> > > > sysadmins.<br>
>> >> > > > The project's maintainer is the one in charge to \
setup the travis<br> >> >> > > > configuration file (if he wants \
to), in order to have working<br> >> >> > > > builds.<br>
>> >> > > ><br>
>> >> > > > Would this be possible from a technical p.o.v.? I \
think the KDE<br> >> >> > > > github<br>
>> >> > > > account would have to register on the travis website \
and "sync"<br> >> >> > > > its<br>
>> >> > ><br>
>> >> > > github<br>
>> >> > ><br>
>> >> > > > repositories - that's what I had to do with my \
personal github<br> >> >> > > > account.<br>
>> >> > > ><br>
>> >> > > > The use cases could be many. For example, on travis \
I can install<br> >> >> > ><br>
>> >> > > optional<br>
>> >> > ><br>
>> >> > > > dependencies that are not available on our Jenkins \
installation.<br> >> >> > > > More<br>
>> >> > > > details in this post [3].<br>
>> >> > > ><br>
>> >> > > ><br>
>> >> > > > What do you think?<br>
>> >> > ><br>
>> >> > > I don't see the point in having two CI systems, just \
help improve<br> >> >> > > the<br>
>> >> > > one<br>
>> >> > > we<br>
>> >> > > have.<br>
>> >> > ><br>
>> >> > > If you need dependencies, why did you start a new CI \
system instead<br> >> >> > > of<br>
>> >> > > asking<br>
>> >> > > for the dependendies to be installed?<br>
>> >> ><br>
>> >> > Well I did ask, but those deps are not available in the \
Ubuntu<br> >> >> > repositories<br>
>> >> > currently used by Jenkins.<br>
>> >> > Maybe a solution could be to install them from \
source/manually, but<br> >> >> > that<br>
>> >> > requires work from the sysadmins, who have already enough in \
their<br> >> >> > plate.<br>
>> >><br>
>> >> I see. Maybe you can offer to help them?<br>
>> ><br>
>> ><br>
>> > Not sure I have enough skills (especially now that we use docker), but \
I<br> >> > can<br>
>> > ceirtainly try. Should I contact Ben?<br>
>><br>
>> Docker shouldn't complicate things too much - it's essentially \
an<br> >> enhanced chroot.<br>
>> If you're considering depending on this, have you spoken with the<br>
>> Kubuntu packagers regarding getting this (hopefully non-Qt dependent)<br>
>> dependency packaged?<br>
>><br>
>> If it's Qt based, I do hope it isn't using QMake.<br>
><br>
><br>
> They are not Qt based. In Ark we have (optional) tests that relies on<br>
> packages such as unrar/rar and unarchiver. Both seems not packaged in the<br>
> ubuntu version used by Jenkins.<br>
> I'm fine with running these tests only locally on my system, but if there \
is<br> > something I can do to have them in our CI would be super-awesome.<br>
<br>
</div></div>We run Ubuntu Wily as our base. Have you checked to see whether 16.04<br>
will contain these utilities?<br>
I suspect unrar/rar will be missing due to it's proprietary \
nature.<br></blockquote><div><br></div><div>This is correct. That's why we \
introduced a plugin for unarchiver in the first place.<br></div><div>Yet it looks \
like they are both available in wily, respectively in the multiverse [1][2] and \
universe [3] repos.<br><br></div><div>Would be possible to have at least \
[3]?<br></div><div><br>[1]: <a \
href="http://packages.ubuntu.com/wily/unar">http://packages.ubuntu.com/wily/unar</a><br>[2]: \
<a href="http://packages.ubuntu.com/wily/rar">http://packages.ubuntu.com/wily/rar</a><br>[3]: \
<a href="http://packages.ubuntu.com/wily/unar">http://packages.ubuntu.com/wily/unar</a><br><br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
Cheers,<br>
Ben<br>
<div class=""><div class="h5"><br>
><br>
>><br>
>><br>
>> Regards,<br>
>> Ben<br>
>><br>
>> ><br>
>> >><br>
>> >><br>
>> >> > I did not start a new CI, I was basically playing with travis \
for<br> >> >> > fun.<br>
>> >> > But<br>
>> >> > then it turned out that it could solve an issue I have. The \
travis<br> >> >> > infrastrucure is already there, why not use it if \
one or more<br> >> >> > projects<br>
>> >> > could benefit? Seems a win-win to me.<br>
>> >><br>
>> >> As a release team member i won't look at the github CI<br>
>> >><br>
>> >> I will look at our official one, but you will look at the github \
one<br> >> >> since<br>
>> >> for<br>
>> >> you "it's better"<br>
>> ><br>
>> ><br>
>> > I never said it's better. I think it would be a nice addition, \
doesn't<br> >> > mean<br>
>> > that I would stop looking at our main CI<br>
>> ><br>
>> >><br>
>> >><br>
>> >> I can see this creating problems, like for example <a \
href="http://build.kde.org" rel="noreferrer" target="_blank">build.kde.org</a><br> \
>> >> passing<br> >> >> and<br>
>> >> githubCI not passing and you getting mad at me because we \
released<br> >> >> something<br>
>> >> that doesn't work.<br>
>> ><br>
>> ><br>
>> > This is a fair point, but see also my previous reply to Luca (the \
"who<br> >> > cares" part).<br>
>> > I can promise you that I won't get mad at you, fwiw :)<br>
>> ><br>
>> >><br>
>> >><br>
>> >> Cheers,<br>
>> >> Albert<br>
>> >><br>
>> >> ><br>
>> >> > > Cheers,<br>
>> >> > ><br>
>> >> > > Albert<br>
>> >> ><br>
>> >> > Cheers,<br>
>> >> > Elvis<br>
>> >> ><br>
>> >> > > > Regards,<br>
>> >> > > > Elvis<br>
>> >> > > ><br>
>> >> > > ><br>
>> >> > > > [1]: <a href="https://github.com/KDE" \
rel="noreferrer" target="_blank">https://github.com/KDE</a><br> >> >> \
> > > [2]: <a href="https://travis-ci.org/" rel="noreferrer" \
target="_blank">https://travis-ci.org/</a><br> >> >> > ><br>
>> >> > > > [3]:<br>
>> >> > ><br>
>> >> > ><br>
>> >> > > <a \
href="http://www.aelog.org/travis-ci-builds-of-kde-projects-on-archlinux-chroot/" \
rel="noreferrer" target="_blank">http://www.aelog.org/travis-ci-builds-of-kde-projects-on-archlinux-chroot/</a><br>
>> >><br>
>> >><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic