Missing CI on meta-qcom-distro

[ndechesne]

This repo still does not have a proper CI for PR. I want to start a discussion on what we want to do in terms of CI here. Especially since we have lots of CI workflows/scripts existing in meta-qcom. I would like to define what the 'proper' CI should be for meta-qcom-distro.

What do we need which is missing today:

1. Test incoming PR. Build & run tests for each new PR. I think we should test meta-qcom-distro with meta-qcom, not in standalone
2. yocto-check-layer for meta-qcom-distro
3. 'world' build for meta-qcom-distro like we did for meta-qcom

I want to avoid any duplication of workflows between meta-qcom and meta-qcom-distro.

Questions:

1. We still need to test incoming meta-qcom PRs with meta-qcom-distro (to make sure a meta-qcom PR does not break meta-qcom-distro!). Should we keep building meta-qcom-distro (e.g. DISTRO=qcom) in the meta-qcom CI? If no, can we define a mechanism/pipeline to "forward" the meta-qcom PR to meta-qcom-distro (workflow call?) and test it in meta-qcom-distro? We need to ensure that the meta-qcom PR will fail if the meta-qcom-distro with this PR fails.
2. Should we share the sstate-cache and DL_DIR for meta-qcom and meta-qcom-distro CI?

Sooner or later, we will need to extend this mechanism to meta-qcom-3rdparty. e.g. we will want to check that a meta-qcom or meta-qcom-distro PR does not break the meta-qcom-3rdparty layer.

[ricardosalveti]

We should share sstate-cache between projects if possible, that won't hurt.

I guess the question is really if we can trigger jobs from one project into another, and force some level of dependency between them for both build and test execution, as we also want to satisfy auto-merge by linking jobs from multiple repos, which I'm not so sure that is possible in github yet.

[ndechesne]

cc @mynameistechno . he might know what we can vs cannot do with Github Actions

[mynameistechno]

I'd need more time to look at this properly, but I recall you can have one workflow trigger another workflow via API call or e.g. https://github.com/benc-uk/workflow-dispatch

kernel-topics has done something similar, but there were limitations (that are escaping me now) and they ended up using a GitHub App. I think those issues may have been related to workflows not existing in the default branch, which may not apply here.

@njjetha do you recall what the issue was?

Is the sstate-cache stored in AWS EFS today?