[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:53:15
Message-ID: CALN1cnsM3DsCVO5seVtif3yJ8G3ZLw0mx9zsbH0doBXRDVE-0Q () mail ! gmail ! com
[Download RAW message or body]

2016-04-21 9:32 GMT+02:00 Harald Sitter <sitter@kde.org>:

> On Wed, Apr 20, 2016 at 6:42 PM, Elvis Angelaccio
> <elvis.angelaccio@kdemail.net> wrote:
> > 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?
>
> Just have the main devs do a double push to an unoffical mirror...
>
> $ cat .git/config | grep pushurl
>        pushurl = kde:releaseme
>        pushurl = git@github.com:apachelogger/releaseme.git
>
> FWIW, I find it sad that as a community we apparently don't have
> enough integrity so we can enable support for a third party CI tool
> without having it undermine our tool, which just BTW doesn't even play
> in the same league as far as large scale stack integration goes.
> What sort of culture is that anyway where we stand in the way of devs
> trying to make things more awesome because of "oh but this might maybe
> will happen". I am so incredibly disappointed.
>

Hi Harald,
the double push looks like a good trade-off to me! Thanks for sharing


>
> HS
>

[Attachment #3 (text/html)]

<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-04-21 \
9:32 GMT+02:00 Harald Sitter <span dir="ltr">&lt;<a href="mailto:sitter@kde.org" \
target="_blank">sitter@kde.org</a>&gt;</span>:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span \
class="">On Wed, Apr 20, 2016 at 6:42 PM, Elvis Angelaccio<br> &lt;<a \
href="mailto:elvis.angelaccio@kdemail.net">elvis.angelaccio@kdemail.net</a>&gt; \
wrote:<br> &gt; Hi,<br>
&gt; as many of you already know, KDE has a github mirror in place at [1].<br>
&gt; I&#39;ve been playing with travis-ci [2] and I was surprised by how easy to \
use<br> &gt; and how well integrated with github is.<br>
&gt;<br>
&gt; I think it would be nice to have travis builds for the (mirrored)<br>
&gt; repositories that provides a .travis.yml configuration file. The builds<br>
&gt; would run on the travis servers, so no additional overload on the KDE<br>
&gt; infrastructure. There is also virtually nothing to do for KDE sysadmins. The<br>
&gt; project&#39;s maintainer is the one in charge to setup the travis \
configuration<br> &gt; file (if he wants to), in order to have working builds.<br>
&gt;<br>
&gt; Would this be possible from a technical p.o.v.? I think the KDE github<br>
&gt; account would have to register on the travis website and &quot;sync&quot; its \
github<br> &gt; repositories - that&#39;s what I had to do with my personal github \
account.<br> &gt;<br>
&gt; The use cases could be many. For example, on travis I can install optional<br>
&gt; dependencies that are not available on our Jenkins installation. More<br>
&gt; details in this post [3].<br>
&gt;<br>
&gt;<br>
&gt; What do you think?<br>
<br>
</span>Just have the main devs do a double push to an unoffical mirror...<br>
<br>
$ cat .git/config | grep pushurl<br>
           pushurl = kde:releaseme<br>
           pushurl = git@github.com:apachelogger/releaseme.git<br>
<br>
FWIW, I find it sad that as a community we apparently don&#39;t have<br>
enough integrity so we can enable support for a third party CI tool<br>
without having it undermine our tool, which just BTW doesn&#39;t even play<br>
in the same league as far as large scale stack integration goes.<br>
What sort of culture is that anyway where we stand in the way of devs<br>
trying to make things more awesome because of &quot;oh but this might maybe<br>
will happen&quot;. I am so incredibly \
disappointed.<br></blockquote><div><br></div><div>Hi Harald,<br></div><div>the double \
push looks like a good trade-off to me! Thanks for sharing<br></div><div>  \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <span class="HOEnZb"><font color="#888888"><br>
HS<br>
</font></span></blockquote></div><br></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]