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.

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.

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.

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.

7heo.

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

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

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

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

Hi 7heo

Am 12.07.2017 um 03:23 schrieb 7heo:
> Jenkins is a terrible, bloated software, that is a gigantic pain to install and maintain, let alone use.
>...

Sorry to say that but this kind of answer let me always think if I need 
to laugh or beeing angry. I'm hearing such statements always from people 
who came from a pure Unix a/o Linux world, who see Java as the 
Armageddon of the IT and not even have an idea of the power and 
possibilities which a tool like Jenkins offers. So it sounds like the 
common answer, unfortunately. :-(

Build automation or CI/CD in general is my daily business and I know the 
different available tools. If you say it's a "gigantic pain to install 
and maintain", then I'd like to know which part is the real pain. Where 
is there something difficult a/o expensive? And even the "bloated" 
argument, for me inappropriate. Why/how do you came to such conclusions?

To let Jenkins run for some testing and play around, you simply need to 
type _one_ line! Even to install it as a service is a common task. You 
can customize Jenkins exactly for your needs, that's the power of a 
plugin system. You can scale it exactly to your requirements. I'm 
maintaining different Jenkins installations with hundreds and even 
thousands of jobs and there are all kinds of jobs with of course a 
majority of build jobs. So you can automate nearly everything with it or 
even let setup build jobs fully automated by Jenkins itself.

Not to just talk without some facts: Beside my daily business Jenkins 
administration I'm maintaining the Jenkins instance of the OSS projects 
fli4l [1] and eisfair [2]. The distro eisfair-ng is based on Alpine 
Linux and the CI of eisfair-ng [3] is fully automated and builds our 
packages. If a new package was added, the corresponding Jenkins job will 
be generated automatically and some minutes after a Git push the new 
package is available on the pkg repo.

"In the end, and to go back on topic" to use your words, you really 
suggest to use minimalistic solutions because of Alpine's goal to be a 
minimalistic distro? Interesting! I think most of the users do _not_ use 
minimalistic tools around Alpine as their base system. Why would someone 
do this? Why should I resign to some comfort if it is just available? 
How do you write Emails or Documents? How do you develop software? Even 
if I'm very happy that there are base tools like vi available as an 
anchor in case of whatever can happen, I'm happy to use comfortable 
tools around the Alpine base system. But anybody as he wishes. If it's 
ok for you to build using some kind of cron jobs, why not. ;-)

Unfortunately the day is always too short with only 24 hours, so I 
cannot bring in more time for such tasks on Alpine itself. I even got 
problems to find enough time for fli4l and eisfair-ng so we also spot 
the issue with not enough man power. So I hope the Alpine'ians find a 
proper solution for their CI/CD.

Kind regards,
Yves


(A sidenote: At the moment we struggle with our EOL hardware. This is 
the reason why there are a lot of jobs on [3] currently disabled or not 
at the latest version. As soon as this is solved the whole system will 
be setup to build for the latest Alpine release.)

[1] https://www.fli4l.de/
[2] https://www.eisfair.org/
[3] https://ssl.nettworks.org/ci/



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Il 2017-07-12 15:22 Breno Leitao ha scritto:
> 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

FWIW, I've packaged jenkins, it's in testing.
With edge doesn't work due to the ttf-dejavu package that is broken 
(https://bugs.alpinelinux.org/issues/7446).
But tbh I didn't go trought this too much, since in 3.6 it works nicely 
and out-of-the-box.
I will take a deeper look on monday, since I'll be away for this 
weekend.
See you climbers!

-- 
:: Francesco Colista
:: Alpine Linux Infrstraucture
:: http://www.alpinelinux.org
:: GnuPG ID: C4FB9584


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---