Over in the OpenBMC project, we rebased on yocto master (https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/37488). After this we started seeing intermittent issues with our os-release.bb recipe. We have a .bbappend in our meta-phosphor layer (https://github.com/openbmc/openbmc/blob/583147ea45f94ee363e9ae30ccb65b9ed1561b54/meta-phosphor/recipes-core/os-release/os-release.bbappend) that issues git commands to use the git hash to fill in our os-release.

After updating to the latest poky, sometimes the build works fine, other times we run into https://github.com/openbmc/openbmc/issues/3720

ERROR�[0m: �[31mWhen reparsing /var/lib/jenkins-slave/workspace/ci-meta/distro/ubuntu/label/docker-builder/target/witherspoon/openbmc/meta/recipes-core/os-release/os-release.bb:do_compile, the basehash value changed from 5da39bb75d4e4256ff7e589f6204c0ee79f16031e54aa78a23d630633becceac to c266b6051c26e27a7f5585d632b703511a7a9657fa2960515b570d3ef54a8ef2. The metadata is not deterministic and this needs to be fixed.�[0m

After some debug, it appears as if occasionally, bitbake is using the sstate cached os-release initially, and then during the build process it moves to using the correct hash id. This then causes the above error. We had issues with this way back in the day when we first introduced this bbappend and the solution was to add this to that recipe:

BB_DONT_CACHE = "1"

I don't see anything in that commit list from poky that looks suspicious but it definitely started happening when we brought that in. I tried modifying our os-release.bbappend to only run once during the compile phase but that caused issues where sometimes the os-release field in our flash image was incorrect (https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/37705 is the revert of that try)