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

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

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://patchwork.openembedded.org/patch/133517/
> >  
> 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.

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.

Henning