We're sharing the sstate-cache on plain Ubuntu LTS machines, all installed from wherever, and no issues with low hitrates.
toggle quoted message
Show quoted text
Even if the build server was running something like ubuntu 14 and "my" machine running 16, the hit rate would still be pretty good, it would only rebuild the "native" stuff, but not the target binaries.
We just share the sstate-cache over HTTP (Apache), so it's a one-way thing - you can get sstate objects from the build server, but not the other way around.
Met vriendelijke groet / kind regards,
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
T: +31 (0) 499 33 69 69
Please consider the environment before printing this e-mail
On 27-05-2020 10:58, Mans Zigher via lists.yoctoproject.org wrote:
This is maybe more related to bitbake but I start by posting it here.
I am for the first time trying to make use of a distributed sstate
cache but I am getting some unexpected results and wanted to hear if
my expectations are wrong. Everything works as expected when a build
node is using a sstate cache from it's self so I do a clean build and
upload the sstate cache from that build to our mirror. If then do a
complete build using the mirror I get a 99% hit rate which is what I
would expect. If I then start a build on a different node using the
same cache I am only getting a 16% hit rate. I am running the builds
inside docker so the environment should be identical. We have several
build nodes in our CI and they where actually cloned and all of them
have the same HW. They are all running the builds in docker but it
looks like they can share the sstate cache and still get a 99% hit
rate. This to me suggests that the hit rate for the sstate cache is
node depending so a cache cannot actually be shared between different
nodes which is not what I expected. I have not been able find any
information about this limitation. Any clarification regarding what to
expect from the sstate cache would be appreciated.