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

[Anton Mikanovich <amikan@ilbers.de>]

Thanks for that digging, I also got the same results: the command was 
executed with the same euid, cwd and HOME values, but tried to access 
~/.config/git/attributes only once for some reason.

24.11.2021 12:30, Schmidt, Adriaan wrote:
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>>>>
>>>> hwork.openembedded.org%2Fpatch%2F133517%2F&amp;data=04%7C01%7Cfe
>>>> lix.mo
>>>> essbauer%40siemens.com%7C8e3a031610c74e6dd76c08d9a9caf3f5%7C38ae3
>>>> bcd95
>>>> 794fd4addab42e1495d55a%7C1%7C0%7C637727511405820881%7CUnknown%
>>>> 7CTWFpbG
>>>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
>>>> 0%
>>>> 3D%7C3000&amp;sdata=od2HCs8VUwZqOzifBdItzcjb5a7j85g33J44%2BiMMjCM
>>>> %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://github.com/ilbers/isar/ 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.
>
> I don't know why that access to $HOME/.config only happens on some of the calls.
>
> Adriaan
>
-- 
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