On Jul 12, 2017 8:56 AM, William Pitcock <nenolod@dereferenced.org> wrote:
>
> Hi,
>
> On Tue, Jul 11, 2017 at 8:23 PM, 7heo <7heo@mail.com> wrote:
> > On Jul 11, 2017 10:13 PM, Roberto Oliveira <rdutra@linux.vnet.ibm.com> wrote:
> >>
> >> 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’s free and well integrated with GitHub. Our build infrastructure uses just a simple shell script for running builds, so it’s currently not usable for this use case.
> >> >
> >> > We would like to improve this, use some real CI software, but haven’t found anything suitable yet. I know Jenkins CI and it’s one of the last CI software I would recommend…
> >> >
> >> > Jakub
> >> >
> >> >> On 11. Jul 2017, at 1:47, Roberto Oliveira <rdutra@linux.vnet.ibm.com> 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 changes in this architecture.
> >> >>
> >> >> Jenkins currently have support for more architectures and we could use it instead of Travis. Jenkins has a plugin called "GitHub pull request builder" that allows to listen when a pull request is opened in GitHub and build with the changes.
> >> >>
> >> >> We could install Jenkins in a machine and create nodes for other machines of different architectures allowing packages to be built in the architectures 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 install 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 very 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 vs product) does not consist enough of a reason to invest the time to even discuss 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 instead. 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 against 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).
Fair enough. I didn't mean to attack Roberto in particular. I understand that having QA on all archs is a wishable goal, but QA on x86_64 alone should already catch the biggest issues.
>
> > In the end, and to go back on topic, Travis has only been used so far because it was there™, but not because we are fanatically supporting it. However, a possible alternative must be sane, and conform with the Alpine 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.
I never understood why redmine has been used. AFAICT it's an artefact of the early infancy of the distribution, and is an exception rather than a rule.
>
> > 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.
Improving test coverage for others archs is work indeed, but I'm afraid it's premature at this point. We just added the support for functionality tests in abuild literally weeks ago; and supporting the other archs in QA isn't going to be a trivial task. There is simply no CI system t I know that does not suck, and I evaluated as many as I could find about 6 months ago.
>
> William