[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 7:41:06
Message-ID: CALN1cnuhmu9JpzwxQn0k1MYTUhsgRyExckmbEq_cvXraGC7m_A () mail ! gmail ! com
[Download RAW message or body]
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.
>
> 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 \
3:07 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
class="HOEnZb"><div class="h5">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 \
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 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 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" 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 the<br> >> > > one<br>
>> > > we<br>
>> > > have.<br>
>> > ><br>
>> > > If you need dependencies, why did you start a new CI system \
instead 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 \
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 can<br>
> ceirtainly try. Should I contact Ben?<br>
<br>
</div></div>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></blockquote><div><br></div><div>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.<br>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.<br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
Regards,<br>
Ben<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>><br>
>> > I did not start a new CI, I was basically playing with travis for \
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 \
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 \
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 \
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> \
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>
>> > > <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>
</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