Add CI workflows by copy/pasting the meta-qcom ones by koenkooi · Pull Request #118 · qualcomm-linux/meta-qcom-distro

koenkooi · 2025-12-16T15:27:42Z

To get CI going on meta-qcom-distro, copy over the meta-qcom workflows with minimal changes.

The changes are:

Drop poky
change 'meta-qcom' rules to list 'meta-qcom-distro'

koenkooi · 2025-12-16T15:28:45Z

Marking this as draft since:

The commits need to get squashed
The commits need better commit messages
This is completely untested

.github/workflows/build-yocto.yml

ndechesne · 2025-12-17T17:34:19Z

.github/workflows/build-yocto.yml

    steps:
      - uses: actions/checkout@v4
+        with:
+          repository: qualcomm-linux/meta-qcom


don't you need to say master here? or is it the default? perhaps better to say it though, so that we have less chances to make a mistake when we branch for LTS!

Should the branch name be extracted as a param? We can do that later, of course. Or maybe we should use GITHUB_BASE_REF / GITHUB_REF here.

koenkooi · 2025-12-19T11:51:52Z

Since the nuts and bolts of this seem to be working, do we want to change the list of machines and images this builds?

.github/workflows/build-yocto.yml

ndechesne · 2025-12-19T12:03:07Z

.github/workflows/build-yocto.yml

+          cache_dir: ${CACHE_DIR}
+          kas: ${KAS_CONTAINER}
+
+  publish_summary:


not for this PR, but we need to figure out how not to duplicate this one, and turn it into a reusable action. can you make a note for it?

.github/workflows/monthly.yml

.github/workflows/nightly-build.yml

ndechesne · 2025-12-19T12:05:16Z

.github/workflows/push.yml

@@ -0,0 +1,31 @@
+name: Build on push


please update README to show the status of HEAD.

Done, not sure how to check that.

.github/workflows/build-yocto.yml

ndechesne · 2025-12-19T12:12:08Z

.github/workflows/test-pr.yml

+
+on:
+  workflow_run:
+    workflows: ["Build on PR"]


the test-pr did not run in your branch. probably because it needs to be merged in master to get the event.. not blocking, but we will need to make sure tests are run when we merge.

.github/workflows/push.yml

.github/workflows/repolinter.yml

.github/workflows/test.yml

lumag

I somewhat dislike the dropping of the build matrix change. It makes this CI to be a downstream of the meta-qcom one. In my opinion, we should be doing exactly the opposite: the meta-qcom should be validated against poky-altcfg (possibly +meta-oe), while this repo should validate the final product: meta-qcom, all our meta-layer-dependencies, etc.

Think about meta-virt breaking one of the recipes. With the proposed workflow it will still affect our meta-qcom builds (which it should not). Instead, meta-virt (again, pure example) issues should only be affecting meta-qcom-distro builds.

.github/workflows/build-yocto.yml

lumag · 2026-01-05T21:21:57Z

.github/workflows/build-yocto.yml

    steps:
      - uses: actions/checkout@v4
+        with:
+          repository: qualcomm-linux/meta-qcom


Should the branch name be extracted as a param? We can do that later, of course. Or maybe we should use GITHUB_BASE_REF / GITHUB_REF here.

ndechesne · 2026-01-05T22:03:16Z

I somewhat dislike the dropping of the build matrix change. It makes this CI to be a downstream of the meta-qcom one. In my opinion, we should be doing exactly the opposite: the meta-qcom should be validated against poky-altcfg (possibly +meta-oe), while this repo should validate the final product: meta-qcom, all our meta-layer-dependencies, etc.

Think about meta-virt breaking one of the recipes. With the proposed workflow it will still affect our meta-qcom builds (which it should not). Instead, meta-virt (again, pure example) issues should only be affecting meta-qcom-distro builds.

I appreciate your comment and share most of it. However we've been procrastinating about meta-qcom-distro CI for months now, and nothing was merged. This PR , as mentioned in the initial log, is to 'get CI going'. We can (and will) optimize/rework the meta-qcom/meta-qcom-distro workflows once we have an initial CI in place (note that we need to think about meta-qcom-3rdparty too). would that work?

lumag · 2026-01-05T22:16:10Z

I somewhat dislike the dropping of the build matrix change. It makes this CI to be a downstream of the meta-qcom one. In my opinion, we should be doing exactly the opposite: the meta-qcom should be validated against poky-altcfg (possibly +meta-oe), while this repo should validate the final product: meta-qcom, all our meta-layer-dependencies, etc.
Think about meta-virt breaking one of the recipes. With the proposed workflow it will still affect our meta-qcom builds (which it should not). Instead, meta-virt (again, pure example) issues should only be affecting meta-qcom-distro builds.

I appreciate your comment and share most of it. However we've been procrastinating about meta-qcom-distro CI for months now, and nothing was merged. This PR , as mentioned in the initial log, is to 'get CI going'. We can (and will) optimize/rework the meta-qcom/meta-qcom-distro workflows once we have an initial CI in place (note that we need to think about meta-qcom-3rdparty too). would that work?

I'd prefer to keep the full matrix here, inside meta-qcom-distro and then drop all meta-qcom-distro jobs from meta-qcom layer.

ndechesne · 2026-01-05T22:23:57Z

I somewhat dislike the dropping of the build matrix change. It makes this CI to be a downstream of the meta-qcom one. In my opinion, we should be doing exactly the opposite: the meta-qcom should be validated against poky-altcfg (possibly +meta-oe), while this repo should validate the final product: meta-qcom, all our meta-layer-dependencies, etc.
Think about meta-virt breaking one of the recipes. With the proposed workflow it will still affect our meta-qcom builds (which it should not). Instead, meta-virt (again, pure example) issues should only be affecting meta-qcom-distro builds.

I appreciate your comment and share most of it. However we've been procrastinating about meta-qcom-distro CI for months now, and nothing was merged. This PR , as mentioned in the initial log, is to 'get CI going'. We can (and will) optimize/rework the meta-qcom/meta-qcom-distro workflows once we have an initial CI in place (note that we need to think about meta-qcom-3rdparty too). would that work?

I'd prefer to keep the full matrix here, inside meta-qcom-distro and then drop all meta-qcom-distro jobs from meta-qcom layer.

me too. but:

this is a drastic change which impact all CI (LAVA tests) and downstream users who are used to get images from meta-qcom, so this might take time to agree/merge
if we make this change, we no longer test meta-qcom-distro as part of meta-qcom CI, which I think we should do one way or the other
So we are back at procrastinating again if we go on that path i think. hence the idea to have a first temporary CI, and then take the time to decide what else we want to do.

lumag · 2026-01-05T22:58:51Z

2. if we make this change, we no longer test meta-qcom-distro as part of meta-qcom CI, which I think we should do one way or the other

I think, it is a proper thing to do. meta-qcom is not dependent on meta-qcom-distro, so issues in meta-qcom-distro (or its dependencies) should not affect meta-qcom.

I would propose to enable full matrix of builds here (as a way to end up procrastination too). Then we can start pointing out people to meta-qcom-distro builds, etc.

ricardosalveti · 2026-01-07T18:46:22Z

if we make this change, we no longer test meta-qcom-distro as part of meta-qcom CI, which I think we should do one way or the other

I think, it is a proper thing to do. meta-qcom is not dependent on meta-qcom-distro, so issues in meta-qcom-distro (or its dependencies) should not affect meta-qcom.

I would propose to enable full matrix of builds here (as a way to end up procrastination too). Then we can start pointing out people to meta-qcom-distro builds, etc.

Yeah, let's duplicate the matrix here and work on moving people to start fetching the jobs (and related testing / lava changes) from this repo instead. We can have the duplicated CI for a few weeks, decide on a date and remove the extra CI from meta-qcom.

We had quite a few build failures over the past few weeks that are really qcom-distro related, so it is good to reduce the CI complexity from meta-qcom soon.

koenkooi · 2026-01-08T12:17:12Z

The yocto-check-layer.sh script turns out to hardcode meta-qcom a lot, so that has to get fixed/duplicated.

This repo needs CI, as a first step copy over the workflow from qualcomm-linux/meta-com.git with the folllowing changes: * Change repository name checks to repo owner checks This should be propagated to all repos using this style of workflows to make sharing of the same code snippets easier. * Change 'meta-qcom' to 'meta-qcom-distro' where approriate And the reverse, specify 'meta-qcom' where things like KAS config files are referenced. * Reuse 'compile' action from meta-qcom.git instead of duplicating it The KAS configuration files and CI helper scripts present in meta-qcom.git/ci/ are being pulled from there for each CI run, they are not being copied or modified. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

The CI only needs to test if the DISTROs work, not the BSPs itself, so restrict the build to the following 3 machines: * qcom-armv7a * qcom-armv8a * rb3gen2-core-kit Restrict the KVM build to qcom-armv8a, it is not supported on armv7a machines. As a consequence: drop the warmup task, it isn't needed with the much reduced scope. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Since we share sstate with meta-qcom, the monthly reaper covers us as well, so drop it from here. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

The CI build here is a subset of meta-qcom.git, so this can be dropped. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

…per repo Checkout meta-qcom-distro and run the layer and patch checker helpers against that, not meta-qcom.git. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

…eta-qcom CI Meta-qcom-distro CI should test all the combinations it supports and not depend on CI from other reps like meta-qcom to accomplish this. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Removing the 'compile_warmpup' step also removed the dependencies the compile step needs. Reinstated those. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

…m and explicity chdir into it Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

…cto-lts KAS configs Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

This now hardcodes 'meta-qcom-distro' and removes the BSP checks, since this isn't a BSP layer. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

ricardosalveti · 2026-01-26T22:26:55Z

As we discussed on slack, closing this one in favor of #139

koenkooi self-assigned this Dec 16, 2025

koenkooi requested review from lumag, ndechesne, ricardosalveti, sbanerjee-quic and vkraleti as code owners December 16, 2025 15:27

koenkooi marked this pull request as draft December 16, 2025 15:27

ndechesne reviewed Dec 17, 2025

View reviewed changes

koenkooi force-pushed the ci-copy/paste branch from 045be35 to 05d76d7 Compare December 18, 2025 08:28

ndechesne reviewed Dec 19, 2025

View reviewed changes

.github/workflows/build-yocto.yml Outdated Show resolved Hide resolved

koenkooi force-pushed the ci-copy/paste branch from 05d76d7 to bebcd02 Compare December 19, 2025 12:09

ndechesne reviewed Dec 19, 2025

View reviewed changes

.github/workflows/build-yocto.yml Outdated Show resolved Hide resolved

ndechesne reviewed Dec 19, 2025

View reviewed changes

.github/workflows/push.yml Outdated Show resolved Hide resolved

.github/workflows/repolinter.yml Outdated Show resolved Hide resolved

.github/workflows/repolinter.yml Outdated Show resolved Hide resolved

.github/workflows/test.yml Outdated Show resolved Hide resolved

koenkooi force-pushed the ci-copy/paste branch from 7d97ae2 to 0f808fd Compare December 19, 2025 15:19

koenkooi force-pushed the ci-copy/paste branch from 0f808fd to 94c5daf Compare January 5, 2026 08:51

lumag requested changes Jan 5, 2026

View reviewed changes

koenkooi added 4 commits January 8, 2026 13:30

Github workflows: drop monthly.yml

9482396

Since we share sstate with meta-qcom, the monthly reaper covers us as well, so drop it from here. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: drop nightly-build.yml

68410cd

The CI build here is a subset of meta-qcom.git, so this can be dropped. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

koenkooi added 13 commits January 8, 2026 13:30

README.md: add CI status banner

f35ecaa

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: build-yocto.yml: run helper scripts against the pro…

4690ba3

…per repo Checkout meta-qcom-distro and run the layer and patch checker helpers against that, not meta-qcom.git. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: use 'main' branch, not 'master' for meta-qcom-distro

c2edbc5

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github Workflows: test.yml: set fetch-depth to '1' instead of '0'

d380fbe

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: reinstate full machine and kernel matrix to match m…

5cf71f9

…eta-qcom CI Meta-qcom-distro CI should test all the combinations it supports and not depend on CI from other reps like meta-qcom to accomplish this. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: fix 'compile' step dependencies

d60b707

Removing the 'compile_warmpup' step also removed the dependencies the compile step needs. Reinstated those. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: build-yocto: be more explicit where to put meta-qco…

cf9c932

…m and explicity chdir into it Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: build-yocto: don't clone below ./

400b0d0

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: build-yocto: remove references to obsolute linux-yo…

a3b5a03

…cto-lts KAS configs Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

ci/yocto-check-layer.sh: import from meta-qcom, changes hardcodes

882b77f

This now hardcodes 'meta-qcom-distro' and removes the BSP checks, since this isn't a BSP layer. Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: build-yocto: use meta-qcom-distro yocto-check-layer.sh

ab0e977

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github workflows: sync pr.yml with meta-qcom to whitelist doc changes

9fa9b0a

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

Github-workflows: build-yocto: sync with meta-qcom PR1106

a255e43

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

koenkooi force-pushed the ci-copy/paste branch from dc7275c to a255e43 Compare January 8, 2026 12:36

Github Workfows: build-yocto: fix path to kas-cintainer-shell-helper

6f18f62

Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>

quaresmajose mentioned this pull request Jan 20, 2026

Reuse CI from meta-qcom #139

Open

ricardosalveti closed this Jan 26, 2026

Conversation

koenkooi commented Dec 16, 2025

Uh oh!

koenkooi commented Dec 16, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

koenkooi commented Dec 19, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lumag left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ndechesne commented Jan 5, 2026

Uh oh!

lumag commented Jan 5, 2026

Uh oh!

ndechesne commented Jan 5, 2026

Uh oh!

lumag commented Jan 5, 2026

Uh oh!

ricardosalveti commented Jan 7, 2026

Uh oh!

koenkooi commented Jan 8, 2026

Uh oh!

ricardosalveti commented Jan 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Comments