Re: [PATCH v7 0/5] Fix usage of additional apt keys and repos

[Jan Kiszka <jan.kiszka@siemens.com>]

On 20.03.19 07:48, Maxim Yu. Osipov wrote:
> Hi Jan,
> 
> On 3/20/19 7:26 AM, Jan Kiszka wrote:
>> On 19.03.19 22:58, Maxim Yu. Osipov wrote:
>>> Hi Andreas,
>>>
>>> CI build ('scripts/ci_build.sh -q') failed. See
>>> http://isar-build.org:8080/job/isar_mosipov_next/165/console
>>>
>>
>> This is the same error I saw yesterday ("..isar-bootstrap-target/rootfs/dev:
>> not mounted"). And given that this and my build had no overlap in our own
>> patches, it must be something else you should examine because it may affect
>> your patches (next..e13be9cefd87).
> 
> Yep, when I tested my patches CI build passed OK,
> but now I see the same error in overnight build of 'next'.
> 

OK, that makes more sense again.

> 
>>> We may create project for you on isar-build.org so you can run CI build on
>>> isar-build.org before submitting patches to the mailing list.
>>> We just need your github repo name (like
>>> https://github.com/henning-schild-work/isar/)
>>
>> We rather need to find a way to make CI public, the current state is rather
>> suboptimal. It's also not very well integrated with github.
>>
>> In fact, we need to find a way to build Isar in the cloud in general, also for
>> use cases such as https://gitlab.com/cip-project/cip-core/isar-cip-core. And
>> our internal CI is not scaling either. We do know how to do that better
>> (container-based builds, controlled e.g. by gitlab-ci), but not yet how to
>> deploy economically.
> 
> Agreed. To be honest I'm not a big fan of gitlab - it's rather slow.
> Do you have any suggestions regarding other alternatives to gitlab/jenkins?

The speed of gitlab is primarily a matter of how you deploy it (ok, when you
have >25K users and >40K projects like we do at Siemens, there are also other
limits). But this is about where to run the CI builds and tests and how to make
those results available.

Unfortunately, our builds take long and require root permissions. So we cannot
simply use any of the public CI services, that scale well but are limited in
those regards. We need hosting in VMs that we control (and likely also pay for),
but that can also be cloned by other users (copy&paste of deployment recipes).
We played with AWS as well as Google Compute and Kubernetes clusters that spawn
up powerful runners on demand (you can afford running them 24/7). These recipes
aren't complete yet, unfortunately, and tuning them takes some time. That's why
this isn't ready yet. I'll try to prioritize that topic as it is becoming a
bottleneck in many projects.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux