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

["Moessbauer, Felix" <felix.moessbauer@siemens.com>]

> -----Original Message-----
> From: Henning Schild <henning.schild@siemens.com>
> Sent: Wednesday, November 17, 2021 5:55 PM
> To: Anton Mikanovich <amikan@ilbers.de>
> Cc: Moessbauer, Felix (T RDA IOT SES-DE) <felix.moessbauer@siemens.com>;
> isar-users@googlegroups.com
> Subject: Re: [PATCH v4 0/2] Improve handling of ISAR_RELEASE_CMD
> 
> Am Wed, 17 Nov 2021 16:05:31 +0300
> schrieb Anton Mikanovich <amikan@ilbers.de>:
> 
> > 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%2Fpa
> > >
> tchwork.openembedded.org%2Fpatch%2F133517%2F&amp;data=04%7C01%7C
> feli
> > >
> x.moessbauer%40siemens.com%7C41165dba8b90412ea40208d9a9eaf011%7C3
> 8ae
> > >
> 3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637727648792760989%7CUnk
> nown%
> > >
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> C
> > >
> JXVCI6Mn0%3D%7C3000&amp;sdata=tiU23Wb9SkVh01PyueQHb9i7K4p3YuhmN
> k4Lj3
> > > Bvg8U%3D&amp;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.
> 
> Well once you sed in there you might also get a "dirty" somewhere. The reason
> the output might differ in gitlab is simply the clone depth which defaults to
> something like 50. If your last tag is 534 commits away you will get only g<sha>
> because there are no tags in your not super-deep clone.

I don't think that is the case here. As long as the ISAR_RELEASE_CMD reports the exactly same value for a single bitbake invocation, we are fine.
The value itself doesn't matter and can also change across invocations of bitbake.
That's exactly the point of the patch to correctly detect changes to the environment and reflect them in /etc/os-release.

Just to make sure we are all on the same page:
With this patch, ISAR_RELEASE_CMD is executed in a anonymous function of the image recipe.
By that it runs at bitbake parsing time and sets the variable IMAGE_BUILD_ID to the output of the command.
As this variable is part of the metadata, it must not change during a single bitbake invocation.
Otherwise bitbake reports "metadata is non-deterministic".

However, it is perfectly fine to change the value across builds (e.g. incremental ones and even without a single modification to a recipe).
That will become relevant once SState is enabled:
In case the rootfs is cached, the ISAR_RELEASE_CMD was not executed again, leading to invalid information in /etc/os-release (e.g. by missing a tag).
This is fixed by the patch.

> 
> Workarounds are to tag more often or to clone deeper. I am not sure git
> describe can be told how many commits to consider in the past. So its output
> might simply differ depending on how deep you cloned.

What you describe here is just about unexpected results in /etc/os-release, because the expected git tag is not in the history.
That's a different story and cannot be addressed by ISAR, but only by the user.

Felix

> 
> Henning