Re: git fetcher: does not execute git fetch --tags or similar when HEAD has not changed

Richard Purdie

On Thu, 2020-03-12 at 14:55 +0100, Matthias Schoepfer via Lists.Yoctoproject.Org wrote:
We have noticed the following issue: We keep the versions of out
software by means of tags on the git repositories, i.e. during the
build, somethings like git describe --tags gets called. In yocto,
recipe of SomeLibrary might look then similar to this:


When we build the image, and *then* apply a tag to HEAD, that was
already built before, it seems like the tags are not fetched (my
is git fetcher sees that origins HEAD and local HEAD have the same
and is fine with it).

The error is, that while the correct version is built, it will
itself with a wrong version.

Is this a bug?
Each of the fetcher backends makes some assumptions about what it
considers to be "the same".

For tarballs from whatever source this is easy and we use the hash of
the tarball.

For git, we work off the hash from git itself. If the hash changes, the
source is taken to be different. Hashes of the same data are taken to
be the same.

What we don't do is account for any tag that represents that hash. If
you have some extra part of the build process which is using that as a
factor for the build you would also have to account for it in the task
hashes. Nothing does that by default.

git tags are a pain as they require network access to evaluate and they
break the mirroring structure as you can't know a given tag was fetched
into the mirror.

So no, I'd not define it as a bug, the bug is you're relying on the tag
data but not adding it to the task hashes.

You'd somehow need to inject the "git tag for revision X" output into
the do_fetch task dependencies.

For autorev this happens via:

meta/classes/base.bbclass: d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}"

so you'd need a new version of get_srcrev() and need to inject that
into the vardeps of the fetch task.



Join to automatically receive all group messages.