[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:       Albert Astals Cid <aacid () kde ! org>
Date:       2016-04-20 21:20:23
Message-ID: 4176705.ySXSygkThk () xps
[Download RAW message or body]

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?

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

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]