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. 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/ >> >> >
