ci: workflows/build-yocto: move the sdk build to the second stage #2254
Open
quaresmajose wants to merge 4 commits into
Open
ci: workflows/build-yocto: move the sdk build to the second stage #2254quaresmajose wants to merge 4 commits into
quaresmajose wants to merge 4 commits into
Conversation
quaresmajose
force-pushed
the
sdk
branch
3 times, most recently
from
079c47d to
ddfb16d
Compare
quaresmajose
changed the title
quaresmajose
force-pushed
the
sdk
branch
2 times, most recently
from
88bc8d9 to
773f826
Compare
Test Results 61 files ±0 303 suites ±0 2h 47m 28s ⏱️ - 8m 24s For more details on these failures, see this check. Results for commit 4181053. ± Comparison against base commit 0c252ae. ♻️ This comment has been updated with latest results. |
quaresmajose
force-pushed
the
sdk
branch
2 times, most recently
from
e8bc9e7 to
128ac26
Compare
quaresmajose
requested review from
anujm1,
koenkooi,
lumag,
ndechesne,
ricardosalveti,
sbanerjeeqc and
vkraleti
as code owners
quaresmajose
force-pushed
the
sdk
branch
2 times, most recently
from
1c6ae5c to
b9b5642
Compare
lumag
approved these changes
May 24, 2026
ricardosalveti
approved these changes
May 27, 2026
There are scenarios where the deploy_dir may not exist. This happens, for example, when we skip target builds. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>
The SDK is taking too long, reaching 3 times the build time of the target image. The SDK main pain point It's really in the last image:do_populate_sdk. It currently takes approximately 30 minutes minutes to complete. Perhaps a solution for the SDK would be to move it from the first (warmup) stage to the second stage of the build. Thus, the first stage would finish earlier and the second would begin earlier, with the SDK build starting directly to the image deployment. However, the gains weren't significant because the 30 minutes will always be necessary; we were just doing part of that in parallel with the other builds of the second stage. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>
This will allow us to define the name outside the block,
so it can be customized depending on how the block will be used.
This also allows you to shorten the name displayed in the UI when
the block is skipped and not executed:
-| ${{matrix.machine}}/${{matrix.distro.name}}${{matrix.kernel.dirname}}
+| inputs.name
Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>
Creating a specific step for buildstats facilitates the analysis of data and allows direct access to this data in the UI. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>
Contributor
|
@quaresmajose @mwasilew did we test it at next? |
Contributor
|
I pushed it to |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The SDK is taking too long, reaching 3 times the build time of the target image.
The SDK main pain point It's really in the last image:do_populate_sdk.
It currently takes approximately 30 minutes minutes to complete.
Perhaps a solution for the SDK would be to move it from the first (warmup) stage
to the second stage of the build. Thus, the first stage would finish earlier and
the second would begin earlier, with the SDK build starting directly to the image
deployment.
However, the gains weren't significant because the 30 minutes will always be
necessary; we were just doing part of that in parallel with the other builds
of the second stage.
buildstats.log example for the best case (when everything comes from sstate-cache):