2016-04-21 9:48 GMT+02:00 Ben Cooksley <bcooks...@kde.org>: > On Thu, Apr 21, 2016 at 7:41 PM, Elvis Angelaccio > <elvis.angelac...@kdemail.net> wrote: > > > > > > 2016-04-21 3:07 GMT+02:00 Ben Cooksley <bcooks...@kde.org>: > >> > >> On Thu, Apr 21, 2016 at 10:07 AM, Elvis Angelaccio > >> <elvis.angelac...@kdemail.net> wrote: > >> > > >> > > >> > 2016-04-20 23:20 GMT+02:00 Albert Astals Cid <aa...@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 <aa...@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/ > >> >> > >> >> > >> > > > > > >
