-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lmp/bb-build: only use the sstate-cache mirror on the first step #359
base: master
Are you sure you want to change the base?
lmp/bb-build: only use the sstate-cache mirror on the first step #359
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are 2 typos on the commit log
fisrt
populadted
The description is confusing to me, maybe, instead of saying "first step" and "second step", say the command? Because there are other bitbake steps, so which you mean by first?
68bf732
to
f6991d9
Compare
I have updated the commit, hope it is more clear now
|
Our build can be divided into two steps: 1 - build only using the sstate-cache 2 - build everything else missing On the step [1] we run bitbake for setscene only tasks and obvious this one is the only one that uses and reads the sstate-cache mirror. The step [2] will have 0% hit of cache available because everything has already been accelerated in the step [1]. In the step [2] everything will be build from scratch and the local sstate-cache will be populated with the new artifacts. This change will improve and significantly reduce the load generated on the sstate-mirror http server by our CI builds. Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
f6991d9
to
1da0a40
Compare
@quaresmajose I understand the reduced load on the server side, but did you measure if this also have any impact on the build time during the CI run? |
I am testing this on the scarthgap factory but I didn't measure the time. |
In theory the build time should be about 2 minutes less, which is the time we waste asking the http server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
btw, in our CI, don't we have access to the sstate mirror through NFS by any chance? |
The internal sstate mirror of the factory (every factory has its own) works through NFS but the public only in HTTPS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
On the fisrt build step we run bitbake for setscene only tasks and obvious this one is the only one that use the reads and use the sstate-cache.
The second step will be a 0% hit of available because everything has already been accelerated in the first step. In this second step everything will be build from scratch and the local sstate-cache populadted with the artifacts.
This will improve and significantly reduce the load generated on the sstate-mirror http server by our CI builds.