I have a customer with some questions about Yocto and SHA:
Some background - our yocto/linux releases are based on your releases, i.e. we start with the manifest from the Freescale release at meta-fsl-bsp-release.git (home of the Freescale i.MX Yocto BSP Release Layer), we add our stuff to it, and then we create our own manifest. Like your manifest, our release manifest locks down all of the components of the build by specifying each layer with its unique SHA (except that yours picks up meta-fsl-bsp-release.git by a branch name, ours specifies the SHA).
The problem - we cannot reproduce some of our builds because some of the versions in meta-fsl-bsp-release have been removed.
For example, one of our builds was looking for the commit with SHA 16c911d. It no longer exists, but with some investigation we were able to determine that the commit had moved to SHA 218af699b.
Was it an accident that commits were removed from the repository? Or is this part of your process and thus a recurring thing, and we'll have to adjust our process? Maybe we shouldn't be referring to your layer through a SHA? This seems somewhat untethered to reproduce builds reliably. But, maybe I'm missing something.
Thanks, any help or insight is appreciated.
Here is the response from customer.
The problem is that when Freescale updates the release layer they are apparently doing it in a way that results in commits being removed from the repository. We lock down the Freescale layer in our builds based on the SHA of the commit that is present at the time of our release. We've gone back to reproduce previous builds and cannot do so because the SHA/commit no longer exists in the Freescale repository. In other words, someone over at Freescale is removing/rewriting the commit history in the repository. Perhaps ask Freescale if it is normal for SHAs to disappear from their repository? Maybe this is done on purpose? But if so, how is anyone expected to identically reproduce a specific release?
My apologies. I would suggest not using specific SHA commits but if possible use branches or the BSP release tags, these may change to a different commit due to fixes or updates but will remain as pointers.