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

["Maxim Yu. Osipov" <mosipov@ilbers.de>]

Hi Andreas, Jan,

On 3/20/19 8:12 AM, Jan Kiszka wrote:
> 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.


1) I've analyzed the two last build failures in 'next' branch - the 
reason is quite stupid - some of the packages can't be downloaded:

For http://isar-build.org:8080/job/isar_next/258/console - libprocps3,
for http://isar-build.org:8080/job/isar_next/259/console - ncurses-bin.

2) As for build with Andreas v7 patch seriesthe failure is related to 
keys stuff (raspbian-jessie-armhf):

ERROR: mc:rpi-jessie:isar-bootstrap-target-1.0-r0 do_bootstrap: Function 
failed: do_bootstrap (log file is located at 
/workspace/build/isar_mosipov_next/165/build/tmp/work/raspbian-jessie-armhf/isar-bootstrap-target/temp/log.do_bootstrap.12981)
ERROR: Logfile of failure stored in: 
/workspace/build/isar_mosipov_next/165/build/tmp/work/raspbian-jessie-armhf/isar-bootstrap-target/temp/log.do_bootstrap.12981
Log data follows:
| DEBUG: Executing shell function do_bootstrap
| I: Running command: debootstrap --arch armhf --foreign --verbose 
--variant=minbase 
--include=locales,gnupg2,apt-transport-https,ca-certificates 
--components=main,contrib,non-free,firmware jessie 
/workspace/build/isar_mosipov_next/165/build/tmp/work/raspbian-jessie-armhf/isar-bootstrap-target/rootfs 
http://archive.raspbian.org/raspbian
| I: Retrieving InRelease
| I: Checking Release signature
| E: Release signed by unknown key (key id 9165938D90FDDD2E)
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_bootstrap (log file is located at 
/workspace/build/isar_mosipov_next/165/build/tmp/work/raspbian-jessie-armhf/isar-bootstrap-target/temp/log.do_bootstrap.12981)
NOTE: recipe isar-bootstrap-target-1.0-r0: task do_bootstrap: Failed

So, Andreas, please have a look on that.

Regards,
Maxim.

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


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov