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

[Henning Schild <henning.schild@siemens.com>]

Am Wed, 24 Nov 2021 10:30:48 +0100
schrieb "Schmidt, Adriaan (T RDA IOT SES-DE)"
<adriaan.schmidt@siemens.com>:

> 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 wondering where the sudo chroot was put around the RELEASE_CMD
and could not find that. Because that place is just wrong if it does
not also set HOME or use sudo -E or use bash -l. If one wants a proper
shell inside a chroot one needs to "log in" and not inherit env ...
especially not with sudo (which messes with env)

But it seems that no such code is part of isar. But maybe part of the
ilbers ci?

Henning

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