Introduce weekly build workflow to reduce load on nightly - #1418
Viswanath Kraleti (vkraleti) wants to merge 1 commit into
Conversation
Test run workflowTest jobs for commit 95ffb91be25a0aaaec4f5f5da1bb96a95a6fbb8e
|
Test Results 14 files 14 suites 1h 12m 39s ⏱️ For more details on these failures, see this check. Results for commit 5b6aa24a. ♻️ This comment has been updated with latest results. |
|
I agree with the general idea, and we should also move some of the pr builds into nightly as well, we're building way too many duplicated things at this stage. For example, we don't need to build kvm and sota with both qcom-next and 6.18, just building the generic image with 6.18 should already be enough to catch most issues. Then we also do a similar optimization for a weekly if needed. |
95ffb91 to
f8f2d25
Compare
|
Nicolas Dechesne (@ndechesne) Ricardo Salveti (@ricardosalveti) Jose Quaresma (@quaresmajose) I cleanup the patch and made the implementation simpler. Please check once. I am yet to move jobs to weekly. If you agree with this approach I'll add one more commit to move some jobs to weekly. |
f8f2d25 to
5b6aa24
Compare
Viswanath Kraleti (vkraleti)
changed the title
2a07500 to
767f4df
Compare
Dmitry Baryshkov (lumag)
left a comment
Dmitry Baryshkov (lumag)
left a comment
There was a problem hiding this comment.
I think the huge build yaml should be split into reusable parts. Then those parts should be selected via some rules (e.g. weekly, when the file changes, etc.). In the end, the SELinux jobs need to be executed when somebody changes the policy. Likewise 6.18 needs to be built (and tested) for PRs which touch 6.18.
| name: performance | ||
| yamlfile: ':ci/qcom-distro-prop-image.yml:ci/performance.yml' | ||
| kernel: | ||
| type: 6.18 |
There was a problem hiding this comment.
This part can't get in, we need to be testing 6.18 on PRs that change it.
| - sm8750-mtp | ||
| distro: | ||
| - name: qcom-distro-selinux | ||
| yamlfile: ':ci/qcom-distro-selinux.yml' |
There was a problem hiding this comment.
So... How do we make sure that SELinux doesn't regress? Especially on PRs.
|
General comment: one of the options might be to rework separate build and test stages into a single action which builds the image and then tests it (on several hardware pieces). Then it would be easier to schedule build-test actions depending on the conditions. |
I agree with something like this approach. We can move all the matrix to actions and specify some tables with the scheduling and condictons to be used: With that can check if all the condiction meets and run the actions or skip it. However, this adds a lot of complexity that we don't currently have. |
|
|
||
| permissions: | ||
| checks: write | ||
| pull-requests: write |
There was a problem hiding this comment.
These should ideally not be defined at workflow level. I assume this is needed for publish-results only.
Perhaps something that should be done in a separate PR. I can send this once all workflow PRs are merged.
|
Viswanath Kraleti (@vkraleti) can we revisit this one? I would like to spread some of our builds into nightly / weekly. |
Sure, I am also feeling the pain of resetting almost every PR multiple times. |
767f4df to
be5b609
Compare
…kly jobs Introduce a new `mode` input with `daily` or `weekly` as acceptable values in the build-yocto workflow. Define individual warm-up and compile steps for both modes. Move SELinux, SOTA, performance and RT kernel builds from the daily to the weekly job. This helps reduce load on daily CI runs while still ensuring periodic validation of less frequently used configurations. Update nightly, PR, and push workflows to invoke build-yocto with `mode: "daily"` to preserve existing behavior. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
be5b609 to
2bf1719
Compare
6 participants
Currently, some of the builds produced by the nightly workflow are not
consumed on a daily basis. Introduce the
weekly-buildworkflow tohandle builds that are needed less frequently, reducing the load on
nightly builds.