From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7026321669488640000 X-Received: by 2002:a17:907:3f9d:: with SMTP id hr29mr19780840ejc.369.1637754863378; Wed, 24 Nov 2021 03:54:23 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:aa7:c517:: with SMTP id o23ls14000503edq.2.gmail; Wed, 24 Nov 2021 03:54:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJzNd9tObUwuluB7XGxDNznlxK1aNAM6FaFyPngaaCHeApbu6rgZsZVHL0CpCxTn4sDAGh0m X-Received: by 2002:aa7:d695:: with SMTP id d21mr23420786edr.378.1637754862413; Wed, 24 Nov 2021 03:54:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637754862; cv=none; d=google.com; s=arc-20160816; b=xThEJgxwKkB79dLezIlsZTcwDiysVZihELc9PDupshAiYj6/86cqpHOS2Gy2+9MUCg Iaumtm0ElLzkdbuN/Ec+sdb1VjNYOrQLypo1KpDzv/h+XEOdyLYxyiVv4//pU05wRz4E 8IYpwGEtqUvY25AdqZV3frkLqzjUW3SApklDcn/lL4nzB68TpOtUG7p3FFfwvQ+TWCqN q3+/KFYf7km3grOft+BFlb6CnO6fw4GrorHeuUzPdwj0IbxwjPXhuBcU0BUri//Sa57a i92eDHVx3IqF4dROsTEQVQLu1YhhzdIwGeecaFXKJinUg838pYRN90h0C3BHrcu53YYB APeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=TMG++fdBQYpKJmVT+Bm8P065fB9cIXdayhEmlLJBEoU=; b=WPXq46LzNOjiIPBjSFEkO/0mUKs4WEkHx7i5zA5BLVFTxCkxrRPf/V86Tb1uxT8oCs 2BoKUosKkUv81hZkih9xFC40IVgvXgjtkneRiFoRJdCODV4VdCj3/rLNQil1QFSrQRUX B+BS4g5nlS69h8drO5TWEUkvviLbru84YFuD37ChrVTURgYZu+kFb3eKyLa2SlVmyRh4 mr+jqRgJj32MFArw9qln6TWTIB4Ueee66j6pT7jYivlMRd63Yng4Fr7CyjOlFFEYyXrU SOVgFoMZ/d4wMEPzLPC6dgZs8DFS7Gs17PbXPE4wcGv0FxoOXTfrgk+Qu5DNbHHu4JNE e6dw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id d2si678796edk.1.2021.11.24.03.54.22 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Nov 2021 03:54:22 -0800 (PST) Received-SPF: pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Received: from [192.168.67.164] (mm-237-77-214-37.mgts.dynamic.pppoe.byfly.by [37.214.77.237] (may be forged)) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 1AOBsK8h014014 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Nov 2021 12:54:21 +0100 Subject: Re: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD To: Jan Kiszka , "Moessbauer, Felix" , "Schmidt, Adriaan" Cc: "isar-users@googlegroups.com" , "henning.schild@siemens.com" , Baurzhan Ismagulov References: <20211104110507.2358692-1-felix.moessbauer@siemens.com> <4bf7b75d-f431-9a07-96f0-a1168af073d3@ilbers.de> <8836f60a-e1f6-59e6-1343-cdb5902dbf96@ilbers.de> From: Anton Mikanovich Message-ID: <3becc6c5-fdd4-1960-7b47-b4c3f4689586@ilbers.de> Date: Wed, 24 Nov 2021 14:54:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: YNH2ZW7Sgyvv To silence that warning we need to change the upstream (git), because this warning was printed to stdout, not stderr. And of course we can't filter it later, because we can't predict what user can set as ISAR_RELEASE_CMD. But maybe we can just use some other default command. 24.11.2021 14:25, Jan Kiszka wrote: > On 24.11.21 11:15, Moessbauer, Felix wrote: >>> -----Original Message----- >>> From: Schmidt, Adriaan (T RDA IOT SES-DE) >>> Sent: Wednesday, November 24, 2021 10:31 AM >>> To: Anton Mikanovich ; Moessbauer, Felix (T RDA IOT >>> SES-DE) >>> Cc: isar-users@googlegroups.com; Schild, Henning (T RDA IOT SES-DE) >>> ; Baurzhan Ismagulov >>> Subject: RE: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD >>> >>> Anton Mikanovich, 22. November 2021 16:28: >>>> To: Moessbauer, Felix (T RDA IOT SES-DE) >>>> >>>> Cc: isar-users@googlegroups.com; Schild, Henning (T RDA IOT SES-DE) >>>> ; Schmidt, Adriaan (T RDA IOT SES-DE) >>>> ; Baurzhan Ismagulov >>>> Subject: Re: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD >>>> >>>> 17.11.2021 18:57, Moessbauer, Felix wrote: >>>>>> -----Original Message----- >>>>>> From: Anton Mikanovich >>>>>> Sent: Wednesday, November 17, 2021 2:06 PM >>>>>> To: Moessbauer, Felix (T RDA IOT SES-DE) >>>>>> >>>>>> Cc: isar-users@googlegroups.com >>>>>> Subject: Re: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD >>>>>> >>>>>> 17.11.2021 13:45, Moessbauer, Felix wrote: >>>>>>> Hi Anton, >>>>>>> >>>>>>> Unfortunately I cannot reproduce this, but this is very likely >>>>>>> related to >>>> a not >>>>>> idempotent ISAR_RELEASE_CMD. >>>>>>> As stated in the API changelog, the ISAR_RELEASE_CMD shall be >>>>>>> idempotent >>>>>> (and technically must be for MC targets). >>>>>>> By that, no things like timestamps must be included. >>>>>>> >>>>>>> If you point me to the location where the ISAR_RELEASE_CMD is set >>>>>>> for CI >>>>>> builds, I can have a look. >>>>>>> Another issue could be that changes to the git happen during build >>> (e.g. >>>> adding >>>>>> a tag, making the repo dirty, etc...). >>>>>>> In that case (starting with a clean build, ending up with a dirty >>>>>>> one), >>>> the CI >>>>>> generated files have to be added to the .gitignore. >>>>>>> In Yocto there is a lengthy discussion about the idempotence >>>>>>> sanity check >>>> [1] >>>>>> and why recipes have to be written in this way. >>>>>>> Best regards, >>>>>>> Felix >>>>>>> >>>>>>> [1] >>>>>>> >>> https:// >>>>>>> patc >>>>>>> >>> hwork.openembedded.org%2Fpatch%2F133517%2F&data=04%7C01%7 >>> Cfe >>>>>> lix.mo >>>>>> >>> essbauer%40siemens.com%7C8e3a031610c74e6dd76c08d9a9caf3f5%7C38ae >>> 3 >>>>>> bcd95 >>>>>> >>> 794fd4addab42e1495d55a%7C1%7C0%7C637727511405820881%7CUnknown >>> % >>>>>> 7CTWFpbG >>>>>> >>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 >>> M >>>>>> n >>>>>> 0% >>>>>> >>> 3D%7C3000&sdata=od2HCs8VUwZqOzifBdItzcjb5a7j85g33J44%2BiMMjC >>> M >>>>>> %3D&a >>>>>>> mp;reserved=0 >>>>>>> >>>>>> Default ISAR_RELEASE_CMD can be found in >>> meta/classes/image.bbclass as: >>>>>> ISAR_RELEASE_CMD_DEFAULT = "git -C ${LAYERDIR_core} describe -- >>> tags >>>>>> -- dirty --match 'v[0-9].[0-9]*'" >>>>>> which results in something like `v0.7-534-g6752a45` This issue is >>>> reproduced >>>>>> inside Jenkins only, but not locally or in gitlab/kas. >>>>> Then it's likely that Jenkins modifies files in the source tree. >>>>> One thing you could try is to explicitly make the git "dirty", or >>>>> simply >>>> try a static ISAR_RELEASE_CMD. >>>>> Anyways, how should we proceed here? >>>>> >>>>> Felix >>>>>> -- >>>>>> Anton Mikanovich >>>>>> Promwad Ltd. >>>>>> External service provider of ilbers GmbH Maria-Merian-Str. 8 >>>>>> 85521 Ottobrunn, Germany >>>>>> +49 (89) 122 67 24-0 >>>>>> Commercial register Munich, HRB 214197 General Manager: Baurzhan >>>>>> Ismagulov >>>> We've reproduced the issue even locally without CI by manually setting >>>> username, clone and build: >>>> >>>> $ sudo chroot --userspec= /bin/bash -c "cd >>>> /tmp && git clone -b >>>> https://gith >>>> >>> ub.com%2Filbers%2Fisar%2F&data=04%7C01%7Cfelix.moessbauer%40s >>> iemens.com%7C764b1f78193440841ad508d9af2d1949%7C38ae3bcd95794fd4 >>> addab42e1495d55a%7C1%7C0%7C637733430489004007%7CUnknown%7CTW >>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX >>> VCI6Mn0%3D%7C3000&sdata=Z52wROzfuVc2F49yGYmmut7JmJ2I46N% >>> 2Bd911OolR%2Fi4%3D&reserved=0 isar-repo && cd isar-repo && source >>> isar-init-build-env && bitbake mc:qemuamd64-bullseye:isar-image-base" >>>> So the issue is related to chroot build but not only Jenkins. >>> I was able to reproduce, and I'm seeing that sometimes `git describe` returns: >>> >>> warning: unable to access '/root/.config/git/attributes': Permission denied >>> v2.0-1-gf7f18a4-dirty (with the extra warning line in its stdout, which then >>> becomes part of IMAGE_BUILD_ID) >>> >>> So sometimes git wants to access config in $HOME, which is `/root` when you >>> run `sudo chroot`, and thus not readable to the user set via --userspec. It >>> works if you `export HOME=/somewhere/readable/by/user` after entering >>> the chroot. >> Thanks for debugging this. >> IMO this is neither an ISAR issue in general, nor related to the patches. >> The patches just make the misconfiguration visible. >> >> We could get around that by telling git to not consider any user or system config files (this requires a very recent git 2.32): >> export GIT_CONFIG_SYSTEM=/dev/null >> export GIT_CONFIG_GLOBAL=/dev/null >> >> This could be done in the isar-init-build-env. >> However, I am not sure if we really want to do so. >> The ISAR release CMD is provided by the user and by that, also the user should be responsible for a correctly setup environment. >> >> Opinions? > I think it would make sense to silence git error/warning messages in the > default ISAR_RELEASE_CMD definition. But anything else would go beyond > reasonable, specifically due to unpredictable side effects. > > Jan > -- Anton Mikanovich Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov