Subject: Re: [alpine-devel] Change Travis in Alpine Continuous Integration
To: alpine-devel@lists.alpinelinux.org
References: <0MI52u-1dWkGz1LeI-003sj6@mail.gmx.com>
From: Breno Leitao <brenohl@br.ibm.com>
Date: Wed, 12 Jul 2017 10:22:26 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <0MI52u-1dWkGz1LeI-003sj6@mail.gmx.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Message-Id: <15aa6fbe-6066-1e52-f7e6-cb3c221d3f3a@br.ibm.com>

Hello,

> Now that we can all agree that this is a waste of time (if not tell
> me, I'll write a longer mail), let's get some actual work done
> instead.

I am sorry, I think that the problem was not well state before, thus part of
the confusion here. I understand Roberto does not want to change Travis to
Jenkins at Alpine (although the email title). Let me try to address the
problem from a different angle:

Problem:
-------

Currently only x86 is being part of the Alpine CI. We understand that not
testing on non x86 on the CI could be a problem. I personally would like to
know if my hackish changes would break ARM, for example, and CI is what shows
us this.

In fact, non x86 is the platform would take more benefit of CI than x86 in my
opinion, because the developer machines are x86 usually. So, most of the the
changes are usually tested on x86 but rarely on other platforms, thus, the
requirement to have non x86 machines as part of the CI seems important.

My experience with other distros also shows that non x86 breaks up to 7 times
more than x86.[1][2]

If we agree that this is a real problem, then we have several ways to solve it.


Possible solutions:
--------------------

 a) Add ppc64le, s390x and arm to Travis infrastructure.
     Pro: Transparent integration
     Cons: Not something that would be done in the near term.

 b) Use another software to do CI on non-x86 platforms as a POC.

     1) Jenkins:
	Pro: Scripts ready to do github integration
	Cons: Bloated software

     2) Buildbot+Homu
	Pro: More contained software
	Cons: Need a little bit more of handwork.

     3) A customized script
	Pro: Will fit better for Alpine.
	Cons: More work (reivinting the wheel?)

     4) Others?


Looking at the whole thread, I understand that option b.2) is what the
community is suggesting as the best approach, and we would like to stay
aligned with the community, since we might extend it to s390x and ARM later
(Maybe even x86 in the future, if our infrastructure becomes stable/good enough).

With this thread author experiences, Roberto and myself are going to create a
buildbot CI PoC and address better the Pros and Cons. Let's see what we can
do in this area.

Thank you for sharing your experiences,
Breno

[1]  http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-artful.html

[2] http://ftp.unicamp.br/pub/ppc64el/debian/packages/debian/





---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---