WIP: Add KAS configuration in preparation for meta-qcom-hwe style CI

[koenkooi]

This is heavily based on the KAS config from meta-qcom-hwe.git

The meta-qcom layer is locked to a commit that still has initramfs-qcom-image, the build won't start otherwise. This also includes inherits that should not be in the CI config, but in the DISTRO.conf.

[ricardosalveti]

Do you want to have this in place before moving inherits to distro.conf and fixing the meta-qcom issue?

[ndechesne]

1. this is using OE-core+bitbake instead of poky. we need to have this discussion first.
2. I am slightly worried that we are duplicating all CI files here and in meta-qcom-hwe. Should we have all the CI script in meta-qcom-hwe, and have builds with and without meta-qcom-distro, all managed from there? e.g. add qcom-distro.yml file in meta-qcom-hwe?

[mwasilew]

Maybe the build part can be done as reusable action/workflow that can be hosted separately and included in the repository workflows? I'm not 100% sure this is possible, but I can spend some time exploring the idea.

[ricardosalveti]

1. this is using OE-core+bitbake instead of poky. we need to have this discussion first.

I don't think it makes sense to rely on poky for this repo at least, helps avoiding more confusion as well.

2. I am slightly worried that we are duplicating all CI files here and in meta-qcom-hwe. Should we have all the CI script in meta-qcom-hwe, and have builds with and without meta-qcom-distro, all managed from there? e.g. add qcom-distro.yml file in meta-qcom-hwe?

We need to also have CI separated for this repo / project alone, and that would not cover this scenario that well.

[ricardosalveti]

Maybe the build part can be done as reusable action/workflow that can be hosted separately and included in the repository workflows? I'm not 100% sure this is possible, but I can spend some time exploring the idea.

Yeah, that could potentially work.

[ndechesne]

Maybe the build part can be done as reusable action/workflow that can be hosted separately and included in the repository workflows? I'm not 100% sure this is possible, but I can spend some time exploring the idea.

Yeah, that could potentially work.

yes, that would definitely work.

[ndechesne]

1. this is using OE-core+bitbake instead of poky. we need to have this discussion first.

I don't think it makes sense to rely on poky for this repo at least, helps avoiding more confusion as well.

well, what makes sense is to do the same thing on meta-qcom-hwe and meta-qcom-distro. I think.

2. I am slightly worried that we are duplicating all CI files here and in meta-qcom-hwe. Should we have all the CI script in meta-qcom-hwe, and have builds with and without meta-qcom-distro, all managed from there? e.g. add qcom-distro.yml file in meta-qcom-hwe?

We need to also have CI separated for this repo / project alone, and that would not cover this scenario that well.

Why do we need a separate CI ? we can trigger the meta-qcom-distro for PR and so, and reuse the CI from meta-qcom, no? we cannot build meta-qcom-distro without meta-qcom anyway. So perhaps there is a way we can avoid the duplication.

[ricardosalveti]

1. this is using OE-core+bitbake instead of poky. we need to have this discussion first.

I don't think it makes sense to rely on poky for this repo at least, helps avoiding more confusion as well.

well, what makes sense is to do the same thing on meta-qcom-hwe and meta-qcom-distro. I think.

In this case we should probably use bitbake + oe-core + poky on both repos then, just the main poky repo is a bit confusing when you are also testing with another OE distro.

2. I am slightly worried that we are duplicating all CI files here and in meta-qcom-hwe. Should we have all the CI script in meta-qcom-hwe, and have builds with and without meta-qcom-distro, all managed from there? e.g. add qcom-distro.yml file in meta-qcom-hwe?

We need to also have CI separated for this repo / project alone, and that would not cover this scenario that well.

Why do we need a separate CI ? we can trigger the meta-qcom-distro for PR and so, and reuse the CI from meta-qcom, no? we cannot build meta-qcom-distro without meta-qcom anyway. So perhaps there is a way we can avoid the duplication.

Sure, we can check how to avoid duplication for the CI logic itself (hosting them in meta-qcom), what I'm saying is that it makes sense to run CI jobs just for meta-qcom-distro (separated actions in the end).

[ricardosalveti]

@koenkooi so let's have the kas stuff for meta-qcom-distro in meta-qcom and the github workflows for this repo here.

[koenkooi]

@koenkooi so let's have the kas stuff for meta-qcom-distro in meta-qcom and the github workflows for this repo here.

I'll work on having the meta-qcom-distro specific kas stuff in meta-qcom.git.