Re: git fetcher: does not execute git fetch --tags or similar when HEAD has not changed
Matthias Schoepfer
Hi Alexander,
toggle quoted message
Show quoted text
thanks for your message. I will try to explain my issue once again, since it still seems not clearly formulated. We build our images on CI (Jenkins). There, we have a shared download dir, so that we do not have to fetch all sources on every build. This gets shared for our "experimental" builds, that use latest git master HEAD (yes, evil AUTOREV) and our "stable" builds, where only tagged (i.e. no AUTOREV versions) are used. Our software uses the git tag to create a version. So, when on experimental, you might get something like: # ourCoolSoftware --version This is ourCoolSoftware version 1.2.3-3 (gabcdef1) What happens is, that people check their changes on the experimental build. After testing, it is considered for the next release, so they attach a version tag to the git repository and update the _<version>.bb accordingly. Now they build the image with the "stable" profile. But the hash "abcdef1" has not changed. Hence, although we pushed a new tag, yocto git fetcher does not update the cached download git, since git hashes match (same with SRCREV). Which means, even tough we have a recipe ourcoolsoftware_1.2.4.bb with SRCREV="abcdef1..." which will build the correct hash, our software checks the local repository, which is missing the last tag and will still be reporting a wrong version 1.2.3-3 for example. If we were to do a bitbake -c cleanall ourcoolsoftware && bitbake ourcoolimage then we get # ourCoolSoftware --version This is ourCoolSoftware version 1.2.4 (gabcdef1) because we artificially force a complete fetch of the repository. We usually do a clean build (no sstate / tmp / etc.) but we use the download dir, because we do not see why we would need to download gcc etc. every time. A workaround would be to bitbake -c cleanall our packages, but it seems hacky and prone to error (need to keep lists of our used software in at least two places). My question is therefore, if this is a "bug" and if we were to investigate this and propose a patch, if this could this be considered for merge, or if this behaviour is intentional and adding a fetch --tags would be considered harmful in any way. Hope, I could bring my point across now. Thanks and Regards, Matthias On 3/16/20 9:43 AM, Alexander Kanavin wrote:
'devtool upgrade' updates SRCREV to match the version tag that you specify: --
Dr.-Ing. Matthias Schoepfer Mobile: +49 175 2062739 email: matthias.schoepfer@... |
|