X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by lists.alpinelinux.org (Postfix) with ESMTP id 354AD5C4EFC for ; Wed, 12 Jul 2017 06:56:56 +0000 (GMT) Received: by mail-qk0-f174.google.com with SMTP id v17so5653834qka.3 for ; Tue, 11 Jul 2017 23:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vw64z9UabPIJFVodMcCwofc5KWyuL5PtQP+VvQjFcIs=; b=H2ZTTnaU2RBsX89TLTzGspiMXftLVpq/26At3yAduHkOuN7va3IqiYoj8ByAAvFvqN ajPkIQl67Yl6qVeRDNKBspfAMU3PIKfn1iRzWH5HMzm8p4T6YZMYI51QfthQg3ISKFll BYfNX+gJjt26QLCGTG25HtMIGLbM6KLfzzR/oWgOW8en/80WigPNir092Pp65hSvEamj gKs9/Vs7DxqdmFKsEUBKIPYcOz3MsnygJEiFT51VijbOxRQlOCK62h4AH7bNpHeDrsOD /7XS8nzJbG78iIHwhKsQmJo5Ywi1+h4ABs6ohEf5Ba2BnmtFl0K7BgR5NISZ+EUipB1J 1joQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vw64z9UabPIJFVodMcCwofc5KWyuL5PtQP+VvQjFcIs=; b=OEuYZ3DatN0hgy924Jivg4YL0JSLPd6xMcDpcAJU2FpzEJ2HWmFk6PGmV/5lZb4bTp Z1pfXfYqlVJfhlNIcyNIcQi/ugjZhaxk5NHjiP1+mJbQnqBlfJkVSb2SrlYn8/+tGNKG VrKr0uQ9EsfF1DEH9//2IxKsd4BbqPqI18+xj2bYYD+8KsevJJjrYdHfrvTPF+w7irHA qH4+xYsJukP6opObby6wlBwQDcbIs+9q34MxX18kDJ1YzI36QVp7LKCT12DdEBmfQThG +wQoYee6W6cpUjoEZyUYzKjvVb0B+bM8yHDrYJWmO77NUFmGN/sI8SkR5HcVI6xyPe8l LSww== X-Gm-Message-State: AIVw110KFxhdWj9KanVRkXGLl/PTejh3tOtn9M1YZAD/FnNnppLbx0LB 4BoRqBmnM7l93CRm5sR5KBY86kRBY1wU X-Received: by 10.233.235.132 with SMTP id b126mr4675936qkg.262.1499842615573; Tue, 11 Jul 2017 23:56:55 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.200.46.23 with HTTP; Tue, 11 Jul 2017 23:56:54 -0700 (PDT) In-Reply-To: <0MI52u-1dWkGz1LeI-003sj6@mail.gmx.com> References: <0MI52u-1dWkGz1LeI-003sj6@mail.gmx.com> From: William Pitcock Date: Wed, 12 Jul 2017 01:56:54 -0500 Message-ID: Subject: Re: [alpine-devel] Change Travis in Alpine Continuous Integration To: 7heo <7heo@mail.com> Cc: Roberto Oliveira , alpine-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 11, 2017 at 8:23 PM, 7heo <7heo@mail.com> wrote: > On Jul 11, 2017 10:13 PM, Roberto Oliveira wr= ote: >> >> Hi Jakub, >> >> Yes, I was suggesting to use Jenkins instead of Travis to do what Travis >> does now (testing the pull requests). >> >> Travis integrates very well with GitHub but I think Jenkins works nice >> too. Why would you not recommend Jenkins? >> >> >> Regards, >> >> Roberto Oliveira >> >> >> On 07/11/2017 04:21 PM, Jakub Jirutka wrote: >> > Hi, >> > >> > we use Travis CI for testing pull requests (and only for that) because= it=E2=80=99s free and well integrated with GitHub. Our build infrastructur= e uses just a simple shell script for running builds, so it=E2=80=99s curre= ntly not usable for this use case. >> > >> > We would like to improve this, use some real CI software, but haven=E2= =80=99t found anything suitable yet. I know Jenkins CI and it=E2=80=99s one= of the last CI software I would recommend=E2=80=A6 >> > >> > Jakub >> > >> >> On 11. Jul 2017, at 1:47, Roberto Oliveira wrote: >> >> >> >> Hi Folks, >> >> >> >> Alpine CI currently uses Travis to build packages when a pull request= is opened. However Travis only support x86_64 and it just build the change= s in this architecture. >> >> >> >> Jenkins currently have support for more architectures and we could us= e it instead of Travis. Jenkins has a plugin called "GitHub pull request bu= ilder" that allows to listen when a pull request is opened in GitHub and bu= ild with the changes. >> >> >> >> We could install Jenkins in a machine and create nodes for other mach= ines of different architectures allowing packages to be built in the archit= ectures we need. >> >> >> >> What do you think about using using Jenkins instead of Travis? >> >> >> >> >> >> Regards, >> >> Roberto Oliveira > > Hey there. > > Jenkins is a terrible, bloated software, that is a gigantic pain to insta= ll and maintain, let alone use. I agree, we should not use Jenkins. > Travis comes as a service, does not require either of those things, is ve= ry usable and extremely well integrated with github. > > The time of the staff behind Alpine is precious, and having a half-assed = solution available that only has some political advantages (free software v= s product) does not consist enough of a reason to invest the time to even d= iscuss this matter. This is a waste of time. I'm extremely glad Jakub took = the time to answer and state his position against Jenkins where people like= me read the ML and just did their best to forgot what they just read inste= ad. I'm only afraid that more time wasted in such matters is only going to = demoralize and deter the contributors who support sane options that go agai= nst the general FOSS popular consensus (busybox vs coreutils, musl vs glibc= , runit/openrc vs systemd, etc.) and ultimately make alpine yet another GNU= /Linux distribution. I don't think this is constructive, especially considering the request is coming from an Alpine maintainer who is working on ppc64le which has no coverage on Travis. What he is ultimately requesting is that we work on a solution that will allow us to test pull requests against all architectures supported by Alpine. This is a reasonable goal, but again I agree that Jenkins should not be used. With that said, we shouldn't attack him for proposing it as a possible solution to his problem (that x86_64 is the only architecture that has pull request test coverage). > In the end, and to go back on topic, Travis has only been used so far bec= ause it was there=E2=84=A2, but not because we are fanatically supporting i= t. However, a possible alternative must be sane, and conform with the Alpin= e stance so far to avoid bloat and use minimalistic solutions instead. Considering the infrastructure team has Redmine deployed for bug tracking, I don't think "avoidance of bloat and use of minimalistic solutions" is really a stated goal for that team. Either way it's an irrelevant argument -- improving the pull request test coverage is work that is critical to the distribution, and should be done. > 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. Improving test coverage for architectures other than x86_64 is actual work. Indeed, lets get it done. William --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---