workflows: only run qcom-distro with 6.18 kernel on master by mwasilew · Pull Request #2304 · qualcomm-linux/meta-qcom

mwasilew · 2026-05-27T10:10:17Z

There are 2 tracks for running PR tests in meta-qcom branches: master and wrynrose. The build matrix in these branches diverged and qcom-distro with 6.18 kernel is not a separate build on wrynrose. When submitting a PR against wrynrose test workflow from master branch is used. For this reason the workflow from master must implement the logic to select branch specific test plan.

github-actions · 2026-05-27T13:39:18Z

Test run workflow

Test jobs for commit `68bfb9e`

qcom-distro_linux-qcom-6.18
Pass: 207 | Fail: 5 | Total: 231

qcom-distro
Pass: 271 | Fail: 0 | Total: 296

nodistro
Pass: 9 | Fail: 0 | Total: 9

test-reporting-app · 2026-05-27T13:40:05Z

Test Results

103 files ± 0 632 suites ±0 5h 7m 2s ⏱️ - 3m 9s
128 tests + 3 101 ✅ - 24 0 💤 ± 0 27 ❌ +27
6 006 runs - 15 5 934 ✅ - 32 44 💤 - 11 28 ❌ +28

For more details on these failures, see this check.

Results for commit 68bfb9e. ± Comparison against base commit 8917dc1.

lumag · 2026-05-28T04:39:38Z

      testkit_ref: "${{ needs.prepare-env.outputs.testkit-ref }}"
  test-qcom-distro_linux-qcom-6-18:
    needs: [prepare-env]
+    if: ${{ needs.prepare-env.outputs.target-branch == 'master' }}


This becomes too branch-specific. For the wrynose branch we also need to schedule tests using the qcom-next kernels. I'd really prefer to find a way to schedule the tests from the correct branch. Can we use workflow dispatching from here?

Workflows on push event will run using the code from the branch. The only issue we're trying to solve here is pull requests. When using pull_request trigger in the workflow, it runs in the context of forked repository. This means it doesn't have access to the tokens in meta-qcom so the LAVA jobs can't be submitted. When the workflow is triggered by workflow_run or pull_request_trigger it runs in the context of main repository (meta-qcom) and has access to the secrets. The trade-off is that the source code of the workflow is taken from the default branch of the repository, in our case master. I'm reading the docs, but I don't see an option to grant access to the secrets and execute the workflow code from the target branch.

mwasilew · 2026-05-28T10:29:46Z

@lumag this is another approach (pasting here to gather initial comments)

diff --git a/.github/workflows/test-pr.yml b/.github/workflows/test-pr.yml
index ef6d92d4..e5437426 100644
--- a/.github/workflows/test-pr.yml
+++ b/.github/workflows/test-pr.yml
@@ -15,16 +15,38 @@ permissions:
   packages: read

 jobs:
-  test:
-    if: ${{ github.event.workflow_run.conclusion == 'success' }}
-    uses: ./.github/workflows/test.yml
+  determine-target-branch:
+    runs-on: ubuntu-latest
+    outputs:
+      branch: ${{ steps.branch.outputs.value }}
+    steps:
+      - id: branch
+        env:
+          PULL_REQUESTS_JSON: ${{ toJSON(github.event.workflow_run.pull_requests) }}
+        run: |
+          BRANCH=$(echo "$PULL_REQUESTS_JSON" | jq -r '.[0].base.ref // "master"')
+          echo "value=$BRANCH" >> "$GITHUB_OUTPUT"
+
+  test-master:
+    needs: determine-target-branch
+    if: github.event.workflow_run.conclusion == 'success' && needs.determine-target-branch.outputs.branch == 'master'
+    uses: qualcomm-linux/meta-qcom/.github/workflows/test.yml@master
+    secrets: inherit
+    with:
+      build_id: ${{ github.event.workflow_run.id }}
+
+  test-wrynose:
+    needs: determine-target-branch
+    if: github.event.workflow_run.conclusion == 'success' && needs.determine-target-branch.outputs.branch == 'wrynose'
+    uses: qualcomm-linux/meta-qcom/.github/workflows/test.yml@wrynose
     secrets: inherit
     with:
       build_id: ${{ github.event.workflow_run.id }}

   comment-on-pr:
     name: "Comment on PR"
-    needs: test
+    needs: [test-master, test-wrynose]
+    if: always() && (needs.test-master.result == 'success' || needs.test-wrynose.result == 'success')
     runs-on: ubuntu-latest
     steps:

@@ -32,7 +54,7 @@ jobs:
         id: download-result-summary
         uses: actions/download-artifact@v7
         with:
-          artifact-ids: ${{ needs.test.outputs.summary_ids }}
+          artifact-ids: ${{ needs.test-master.outputs.summary_ids || needs.test-wrynose.outputs.summary_ids }}
           path: results_summary

       - name: Download event file
@@ -73,7 +95,8 @@ jobs:
   publish-test-results:
     uses: ./.github/workflows/publish-results.yml
     secrets: inherit
-    needs: [test]
+    needs: [test-master, test-wrynose]
+    if: always() && (needs.test-master.result == 'success' || needs.test-wrynose.result == 'success')
     with:
       commit: ${{ github.event.workflow_run.sha }}
       event_file: artifacts/Event File/event.json

I didn't test it yet. It allows to call test.yml from the target branch but still hardcodes the branch names. From what I understand github doesn't allow to dynamically call

uses: qualcomm-linux/meta-qcom/.github/workflows/test.yml@${{ env.BRANCH }}

Would something like this work from your point of view?

lumag · 2026-05-28T12:37:21Z

@mwasilew that looks ok.

mwasilew · 2026-05-28T12:39:03Z

If you're happy with that let me change this PR implementation and see if it works.

When running tests against PR the test plan is taken from master branch by default. This is due to how workflow_run github trigger works. The default behaviour causes wrynose branch PRs to fail due to differences in the build matrix. This patch attempts to fix the issue by running a branch specific test plan from test.yml workflow. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

mwasilew · 2026-05-28T14:43:44Z

I updated the patch with the branch specific test.yml. This doesn't look great in the actions tab. Here are the examples:
PR against master (or main) in my test repository:

PR against wrynose in my test repository:

The workflow graph looks "incomplete" to me, however I don't think there is a better solution.

lumag · 2026-05-28T14:50:51Z

Yes, that's pretty bad. Can we instead dispatch a testing workflow instead? I.e. detect the branch in the workflow_run trigger and then use that branch to dispatch a new workflow?

mwasilew · 2026-05-28T16:36:29Z

Yes, that's pretty bad. Can we instead dispatch a testing workflow instead? I.e. detect the branch in the workflow_run trigger and then use that branch to dispatch a new workflow?

that's what this patch is doing. test.yml works as "reusable workflow" and it's called from test-pr.yml that is triggered by workflow_run. Ideally it would be possible to pass variables to the call as proposed above:

qualcomm-linux/meta-qcom/.github/workflows/test.yml@${{ env.BRANCH }}

But github doesn't support that. I don't see any other way of dealing with different branches in the PR. IMHO there are 2 options:

a "know all" workflow in the main branch that disables (skips) parts based on the PR target brach
the "dispatcher" workflow (like the current patch) that calls relevant workflows from the proper branches.

I guess only other option is a github app that is implements all the test plan/branch logic.

mwasilew requested review from anujm1, koenkooi, lumag, ndechesne, ricardosalveti and vkraleti as code owners May 27, 2026 10:10

lumag requested changes May 28, 2026

View reviewed changes

mwasilew force-pushed the workflows/run-qcom-6.18-on-master-only branch from 68bfb9e to 1a8711e Compare May 28, 2026 14:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

workflows: only run qcom-distro with 6.18 kernel on master#2304

workflows: only run qcom-distro with 6.18 kernel on master#2304
mwasilew wants to merge 1 commit into
qualcomm-linux:masterfrom
mwasilew:workflows/run-qcom-6.18-on-master-only

mwasilew commented May 27, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented May 27, 2026

Uh oh!

test-reporting-app Bot commented May 27, 2026

Uh oh!

lumag May 28, 2026

Uh oh!

mwasilew May 28, 2026

Uh oh!

mwasilew commented May 28, 2026

Uh oh!

lumag commented May 28, 2026

Uh oh!

mwasilew commented May 28, 2026

Uh oh!

mwasilew commented May 28, 2026

Uh oh!

lumag commented May 28, 2026

Uh oh!

mwasilew commented May 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mwasilew commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented May 27, 2026

Test run workflow

Test jobs for commit 68bfb9e

Uh oh!

test-reporting-app Bot commented May 27, 2026

Test Results

Uh oh!

lumag May 28, 2026

Choose a reason for hiding this comment

Uh oh!

mwasilew May 28, 2026

Choose a reason for hiding this comment

Uh oh!

mwasilew commented May 28, 2026

Uh oh!

lumag commented May 28, 2026

Uh oh!

mwasilew commented May 28, 2026

Uh oh!

mwasilew commented May 28, 2026

Uh oh!

lumag commented May 28, 2026

Uh oh!

mwasilew commented May 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mwasilew commented May 27, 2026 •

edited

Loading

Test jobs for commit `68bfb9e`