Re: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD

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

On 24.11.21 11:15, Moessbauer, Felix wrote:
>> -----Original Message-----
>> From: Schmidt, Adriaan (T RDA IOT SES-DE) <adriaan.schmidt@siemens.com>
>> Sent: Wednesday, November 24, 2021 10:31 AM
>> To: Anton Mikanovich <amikan@ilbers.de>; Moessbauer, Felix (T RDA IOT
>> SES-DE) <felix.moessbauer@siemens.com>
>> Cc: isar-users@googlegroups.com; Schild, Henning (T RDA IOT SES-DE)
>> <henning.schild@siemens.com>; Baurzhan Ismagulov <ibr@ilbers.de>
>> 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)
>>> <felix.moessbauer@siemens.com>
>>> Cc: isar-users@googlegroups.com; Schild, Henning (T RDA IOT SES-DE)
>>> <henning.schild@siemens.com>; Schmidt, Adriaan (T RDA IOT SES-DE)
>>> <adriaan.schmidt@siemens.com>; Baurzhan Ismagulov <ibr@ilbers.de>
>>> 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 <amikan@ilbers.de>
>>>>> Sent: Wednesday, November 17, 2021 2:06 PM
>>>>> To: Moessbauer, Felix (T RDA IOT SES-DE)
>>>>> <felix.moessbauer@siemens.com>
>>>>> 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&amp;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&amp;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=<username> <chroot_path> /bin/bash -c "cd
>>> /tmp && git clone -b <branch>
>>> https://gith
>>>
>> ub.com%2Filbers%2Fisar%2F&amp;data=04%7C01%7Cfelix.moessbauer%40s
>> iemens.com%7C764b1f78193440841ad508d9af2d1949%7C38ae3bcd95794fd4
>> addab42e1495d55a%7C1%7C0%7C637733430489004007%7CUnknown%7CTW
>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
>> VCI6Mn0%3D%7C3000&amp;sdata=Z52wROzfuVc2F49yGYmmut7JmJ2I46N%
>> 2Bd911OolR%2Fi4%3D&amp;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

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux