Reuse CI from meta-qcom by quaresmajose · Pull Request #139 · qualcomm-linux/meta-qcom-distro

quaresmajose · 2026-01-19T17:52:18Z

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

The major changes are:

workflows: import from meta-qcom
workflows: drop unnecessary workflows
workflows: disable tests
workflows/build-yocto: disable yocto-run-checks
workflows: reuse actions
workflows: change branch names
workflows/build-yocto: drop poky-altcfg distro
workflows/build-yocto: add qcom-distro yml local override

Pending changes not ready yet:

The yocto-run-checks
The tests workflows

Heavily based on #118

.github/actions/lava-test-plans/action.yml

mwasilew · 2026-01-20T12:13:57Z

.github/workflows/test.yml


      - name: Run lava-test-plans
-        uses: ./.github/actions/lava-test-plans
+        uses: qualcomm-linux/meta-qcom/.github/actions/lava-test-plans


For this to work lava-test-plans needs to support a project named the same as a repository. In this case meta-qcom-distro. This change needs to go here: https://github.com/qualcomm-linux/lava-test-plans/tree/master/lava_test_plans/projects

I will drop the tests from the workflows for now until we have a more functional and ready system.

In the end I'll leave it as is because it doesn't affect the PR result and allows all the checks to became green.

Up to you. All subsequent PRs will fail.

I removed it to not fail on push.

@mwasilew @quaresmajose I think qualcomm-linux/lava-test-plans#12 will provide necessary changes (at least for now).

.github/workflows/test.yml

ndechesne · 2026-01-22T08:16:48Z

Is this PR replacing #118 ? Why did we revive it here? I thought we were reviewing #118 a couple of weeks ago. Also it's difficult to review a large rework without proper commit messages.

quaresmajose · 2026-01-22T13:04:53Z

Yes this PR is heavily based on #118. Creating a new PR was the easiest way for me to test out my ideas.
The commits meassag haven't been finalized yet because I was still experimenting. However, I was thinking of removing the draft state today or tomorrow and asking for reviews for what is already functional and would continue with new PRs afterwards.

ricardosalveti · 2026-01-26T19:46:32Z

.github/workflows/nightly-build.yml

-  schedule:
-  # NOTE - changes to the cron spec should be pushed by https://github.com/quic-yocto-ci
-  # so that build notification emails will be sent out properly.
-  - cron: "23 23 * * *"   # daily job - pick a random "minute"  - top of hour can be busy in github


Hm, we do need nightly here as well, the main image people are planning on testing are the ones produced with meta-qcom-distro and done nightly.

For now we can have just the main meta-qcom nightly and the artifacts will remain the same. In the next step, we can create artifacts nightly from qcom-disto in this layer and remove them from meta-qcom layer. So we end up with two nightly builds, one per layer, where each one produces its own artifacts.

Could you please leave nightly in place? We will point new users to nightly jobs from meta-qcom-distro, allowing us to gradually fade out meta-qcom builds.

I can leave it as it is, but note that we dont have tests in place yet for meta-qcom-distro nor do we have yocto-check-layer yet. I don't understand your opinion as to why this can't be postponed either.

Because we can point our downstream users to the images built from this layer (and thus being more future-proof) rather than surprising them later with the 'you have been using images from meta-qcom, now please switch to meta-qcom-distro).

When we have the images ready to be consumed here we should remove all qcom distro images from the meta-qcom and keep only the poky-alt distro in that. This clearly will shows what images are provided by each of the repositories, and at this point we can eanble the nightly jobs active in both repositories.

.github/workflows/build-yocto.yml

quaresmajose · 2026-01-27T15:40:33Z

According to qualcomm-linux/meta-qcom#1416, I will also drop the commit workflows/build-yocto: build kvm on qcom-armv8a machine on the next push.

ricardosalveti · 2026-01-28T01:43:03Z

Looking better, let's try to get this merged and validated this week.

ndechesne · 2026-01-28T07:13:10Z

.github/workflows/build-yocto.yml

+        with:
+          path: meta-qcom-distro
+
+      - name: Prepare kas qcom-distro yml


I don't understand this patch. and I don't think we should copy KAS config files here, hidden in CI.

We need to decide if we keep the KAS config files for meta-qcom-distro in meta-qcom (1) or if we move them in meta-qcom-distro (2).

If we pick (1) then we should clone meta-qcom and use the KAS files from there, and find a way to fetch the right commit for meta-qcom-distro (it can be main for a push event, but it can be a PR branch too).

If we pick (2), we should clone meta-qcom-distro and let kas clone meta-qcom

I'm inclined to use (2) and with that we can drop this this patch. But that will have to be done later because it includes changes in both repositories which have to be done in some synchronized way.

Then testing of meta-qcom starts to depend on meta-qcom-distro, which is also not so good.

(3) make a copy of KAS configs in meta-qcom-distro ?

That would create duplication, but at the same time it would allow us to customize per-machine configuration.

It already depends, currently testing of meta-qcom does not work without meta-qcom-distro.
Moving all qcom-distro bits and pieces to meta-qcom-distro layer would eliminate that dependency.
And we would make the distro dependent on BSP, not the other way around.

Please. Duplicate those files.

It's not a questions duplications:

workflows/build-yocto: add qcom-distro yml local override This change is intended only to have a functional build with minimal modifications and is temporary; it will be reverted in subsequent iterations of the distro ci integration. We need the primary repository to be meta-qcom so we can keep using its github/actions with minimal changes. To do this, we'll first checkout meta-qcom as the primary repository and then meta-qcom-distro inside it. The last part we need for this is the new kas config which will allow us to change the layer structure used by kas here. This configuration has the necessary changes for move the meta-qcom-distro layer as well as the differences of meta-qcom layer. Instead of meta-qcom-distro being an external layer like in meta-qcom ci, it becomes a internal layer of meta-qcom here.

.github/workflows/build-yocto.yml

lumag · 2026-01-30T10:20:12Z

.github/workflows/monthly.yml

-      - name: Clean up the persistant sstate-cache dir
-        run: |
-          # keep current and last month to allow smooth end of month transition
-          rm -rf /efs/qli/meta-qcom/sstate-cache-$(date -d '2 months ago' '+%Y-%m')


Will the job from meta-qcom clean the cache for meta-qcom-distro?

for now we've decided to use the same SSTATE_CACHE for meta-qcom and meta-qcom-distro, so yes. are you saying this is a problem?

The deletion cleanup rule is based solely on time, so it doesn't matter if it's done on meta-qcom or meta-qcom-distro.

lumag · 2026-01-30T10:20:39Z

.github/workflows/nightly-build.yml

-  schedule:
-  # NOTE - changes to the cron spec should be pushed by https://github.com/quic-yocto-ci
-  # so that build notification emails will be sent out properly.
-  - cron: "23 23 * * *"   # daily job - pick a random "minute"  - top of hour can be busy in github


Could you please leave nightly in place? We will point new users to nightly jobs from meta-qcom-distro, allowing us to gradually fade out meta-qcom builds.

lumag · 2026-01-30T10:21:41Z

.github/workflows/push.yml

 jobs:
  build:
    uses: ./.github/workflows/build-yocto.yml
-  test:


Could you please create an issue, lightly describing what is the issue with the tests infrastructure and point it from the commit message?

I still don't know what's needed for this task to be completed. I only know that it doesn't work as it is, nor does it depend solely on the code present in the layer. More on this #139 (comment)

qualcomm-linux/lava-test-plans#12 -- will this fit?

Look like it fit our requirments but It would be better to leave that for the next step since it still requires changes in more places like the actions on meta-qcom.

Which changes?

I don't know, but @mwasilew said that more changes were needed.

@mwasilew do you have any idea of what would be missing for enabling testing with meta-qcom-distro?

lumag · 2026-01-30T10:22:56Z

.github/workflows/build-yocto.yml

          path: ci/*.lock.yml

-  yocto-run-checks:
-    needs: kas-setup


Which adaptations are we missing?

The helper scripts on meta-com/ci don't work as they are and need to be changed or duplicated here.

Please duplicate it here and provide necessary fixes.

I prefer to do that later because this PR is already too long and difficult to integrate.

No, it must be a part of the CI, otherwise we can land recipes which break layer compat requirements.

Does the current situation allow you to do that?

I don't think we are calling check-layer with meta-qcom-distro.

.github/workflows/build-yocto.yml

koenkooi · 2026-02-04T12:47:24Z

.github/workflows/build-yocto.yml

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


After we branch for release, this needs to get updated. We could reuse the same branch name, but that would need a git branch aliasfor master<>main in meta-qcom.

It might be possible at a later step of the distro ci integration to fetch this layer using kas like for all the others. So we'll stop specifying this here on the github workflow.

lumag · 2026-02-04T18:46:54Z

.github/workflows/push.yml

 jobs:
  build:
    uses: ./.github/workflows/build-yocto.yml
-  test:


qualcomm-linux/lava-test-plans#12 -- will this fit?

lumag · 2026-02-04T18:48:22Z

.github/workflows/build-yocto.yml

          path: ci/*.lock.yml

-  yocto-run-checks:
-    needs: kas-setup


Please duplicate it here and provide necessary fixes.

.github/workflows/build-yocto.yml

lool · 2026-02-16T15:09:06Z

This looks fairly ready, and we can iterate once it's merged?

To get CI going on meta-qcom-distro, copy over the meta-qcom .github/workflows folder revision c5ef0066e [1]. [1] c5ef0066e Enable TPM Stack (#1504) Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

We can discard the scheduled jobs, nightly-build and monthly, that are already being carried out at meta-qcom ci. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

The tests workflows are not ready and will be proposed later after the first phase. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

The yocto-run-checks step needs adaptations that are not yet complete. We will turn it off since this does not prevent the existing features from working. It will be proposed in the next step. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

We will reuse the actions from the meta-com repository to avoid code duplication. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

The branch name here is main and not master like in meta-qcom. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

We will exercise all qcom-distro distributions variants here. The poky-altcfg is more appropriate for testing the Yocto distributions, and are already tested in the meta-qcom layer. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

This change is intended only to have a functional build with minimal modifications and is temporary; it will be reverted in subsequent iterations of the distro ci integration. We need the primary repository to be meta-qcom so we can keep using its github/actions with minimal changes. To do this, we'll first checkout meta-qcom as the primary repository and then meta-qcom-distro inside it. The last part we need for this is the new kas config which will allow us to change the layer structure used by kas here. This configuration has the necessary changes for move the meta-qcom-distro layer as well as the differences of meta-qcom layer. Instead of meta-qcom-distro being an external layer like in meta-qcom ci, it becomes a internal layer of meta-qcom here. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

quaresmajose force-pushed the meta-qcom-ci branch 3 times, most recently from dc619bc to 7195c8b Compare January 20, 2026 11:58

mwasilew requested changes Jan 20, 2026

View reviewed changes

quaresmajose self-assigned this Jan 20, 2026

anujm1 reviewed Jan 22, 2026

View reviewed changes

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

quaresmajose force-pushed the meta-qcom-ci branch 2 times, most recently from ba3287a to bb97f0a Compare January 22, 2026 17:26

quaresmajose mentioned this pull request Jan 26, 2026

workflows: use the repository owner instead of the name qualcomm-linux/meta-qcom#1437

Merged

quaresmajose force-pushed the meta-qcom-ci branch from bb97f0a to 03d3a7d Compare January 26, 2026 18:44

quaresmajose marked this pull request as ready for review January 26, 2026 18:44

quaresmajose requested review from lumag, ricardosalveti, sbanerjee-quic and vkraleti as code owners January 26, 2026 18:44

ricardosalveti reviewed Jan 26, 2026

View reviewed changes

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

ricardosalveti reviewed Jan 26, 2026

View reviewed changes

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

ricardosalveti reviewed Jan 26, 2026

View reviewed changes

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

ricardosalveti mentioned this pull request Jan 26, 2026

Add CI workflows by copy/pasting the meta-qcom ones #118

Closed

quaresmajose force-pushed the meta-qcom-ci branch from 03d3a7d to 6f20d29 Compare January 27, 2026 15:08

quaresmajose force-pushed the meta-qcom-ci branch from 6f20d29 to c005616 Compare January 27, 2026 16:19

ndechesne reviewed Jan 28, 2026

View reviewed changes

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

quaresmajose force-pushed the meta-qcom-ci branch 2 times, most recently from 2f913fd to 537c570 Compare January 28, 2026 15:30

quaresmajose force-pushed the meta-qcom-ci branch 4 times, most recently from 2823943 to 9a0bcd8 Compare January 30, 2026 10:00

lumag requested changes Jan 30, 2026

View reviewed changes

quaresmajose force-pushed the meta-qcom-ci branch 2 times, most recently from 4d6ece9 to 9dc37bf Compare February 3, 2026 11:36

koenkooi reviewed Feb 4, 2026

View reviewed changes

quaresmajose force-pushed the meta-qcom-ci branch from 9dc37bf to fb7da11 Compare February 4, 2026 18:12

lumag requested changes Feb 4, 2026

View reviewed changes

quaresmajose force-pushed the meta-qcom-ci branch 2 times, most recently from 3096312 to 0804f18 Compare February 9, 2026 15:42

ricardosalveti mentioned this pull request Feb 11, 2026

Guidance on meta-qcom-extras build workflow qualcomm-linux/meta-qcom#1536

Open

quaresmajose force-pushed the meta-qcom-ci branch from 0804f18 to 089d1ac Compare February 16, 2026 14:59

quaresmajose added 7 commits February 16, 2026 17:24

workflows: import from meta-qcom c5ef0066e

f1a1da9

To get CI going on meta-qcom-distro, copy over the meta-qcom .github/workflows folder revision c5ef0066e [1]. [1] c5ef0066e Enable TPM Stack (#1504) Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

workflows: drop unnecessary workflows

619a687

We can discard the scheduled jobs, nightly-build and monthly, that are already being carried out at meta-qcom ci. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

workflows: disable tests

297ba4d

The tests workflows are not ready and will be proposed later after the first phase. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

workflows: reuse actions

0336a1d

We will reuse the actions from the meta-com repository to avoid code duplication. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

workflows: change branch names

6a446d3

The branch name here is main and not master like in meta-qcom. Signed-off-by: Jose Quaresma <jose.quaresma@oss.qualcomm.com>

quaresmajose force-pushed the meta-qcom-ci branch from 089d1ac to c0a602d Compare February 16, 2026 17:24

quaresmajose changed the title ~~Reuse CI defenitions from meta-qcom~~ Reuse CI from meta-qcom Feb 16, 2026

quaresmajose mentioned this pull request Feb 16, 2026

Revert "qcom-multimedia-image: Add gst-plugins-imsdk" #168

Merged

quaresmajose force-pushed the meta-qcom-ci branch from c0a602d to da27bc5 Compare February 16, 2026 18:16

lumag mentioned this pull request Feb 17, 2026

Another view on meta-qcom-distro CI #172

Open

Conversation

quaresmajose commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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!

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!

Uh oh!

ndechesne commented Jan 22, 2026

Uh oh!

quaresmajose commented Jan 22, 2026

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!

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!

Uh oh!

Uh oh!

Uh oh!

quaresmajose commented Jan 27, 2026

Uh oh!

ricardosalveti commented Jan 28, 2026

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!

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!

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!

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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

quaresmajose commented Jan 19, 2026 •

edited

Loading