Skip to content

ci: add build and kernel metadata to LAVA jobs - #3108

Open
Matt H (mattface) wants to merge 1 commit into
qualcomm-linux:masterfrom
mattface:metadata-improvements
Open

Matt H (mattface) wants to merge 1 commit into
qualcomm-linux:masterfrom
mattface:metadata-improvements

Conversation

@mattface

@mattface Matt H (mattface) commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Jobs recorded the build URL, pull request and workflow run, but not the commit they were built from, the configuration under test, or the kernel in the image, and none of it could be queried.

The commit, branch and build type are derived from the event; the machine, distro, kernel, image and test plan the action already knows; the kernel's recipe, repository, commit and release are read from the SPDX SBOM every build already writes and passed over as an artifact.

They are written to a per-machine EXTRA_METADATA variables file passed alongside the existing one, so recording a new key needs no change in lava-test-plans.

This has no effect until the LAVA_TEST_PLANS_REF is bumped, but should quietly not add any metadata until that time.

name: ${{ steps.print-output.outputs.filename }}
path: ${{ steps.print-output.outputs.filename }}

- name: Upload build metadata

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might take us above the allowed artifact threshold (again) quickly. I'm not sure how to prevent the problem. Maybe upload to S3?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Size or count? I can bundle this into the other artifact to keep the count down?

INPUTS_MACHINE: ${{ inputs.machine }}
INPUTS_DISTRO_NAME: ${{ inputs.distro_name }}
INPUTS_KERNEL_DIRNAME: ${{ inputs.kernel_dirname }}
- name: Extract build metadata from the image SBOM

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

turn it into action so you can install python dependencies properly.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theres no python dependencies to install, all are in stdlib I believe

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC you can't assume python is available in the action worker (it's there in most cases). If python is used in the action you should install it like so:

  steps:
...    
      - uses: actions/setup-python@v6
        with:
          python-version: 3.11

@mwasilew

Copy link
Copy Markdown
Contributor

Pushed to next in the current implementation: https://github.com/qualcomm-linux/meta-qcom/actions/runs/34414310119

Comment thread .github/actions/lava-test-plans/action.yml Outdated
@github-actions

github-actions Bot commented Sep 10, 2026

Copy link
Copy Markdown

Test run workflow

Test jobs for commit e89c1cb

qcom-distro
Pass: 0 | Fail: 0 | Total: 0
qcom-distro_linux-qcom-6.18
Pass: 0 | Fail: 0 | Total: 0
nodistro
Pass: 10 | Fail: 0 | Total: 10

@test-reporting-app

test-reporting-app Bot commented Sep 10, 2026

Copy link
Copy Markdown

Test Results

   69 files   -    50    294 suites   - 421   3h 57m 33s ⏱️ - 5h 29m 24s
  151 tests  -    24    149 ✅  -     5   0 💤  -  1  2 ❌  - 18 
1 953 runs   - 2 654  1 938 ✅  - 2 595  12 💤  - 33  3 ❌  - 26 

For more details on these failures, see this check.

Results for commit e89c1cb. ± Comparison against base commit c672971.

This pull request removes 24 tests.
10_Logging_Journalctl_Validation ‑ Logging_Journalctl_Validation
11_Partition_PostBoot_Validation ‑ Partition_PostBoot_Validation
12_Boot_Systemd_KPI_Loop ‑ Boot_Systemd_KPI_Loop
5_OpenCV ‑ OpenCV
6_Ethernet ‑ Ethernet
6_irq ‑ irq
7_BT_ON_OFF ‑ BT_ON_OFF
7_Docker_Kernel_Config ‑ Docker_Kernel_Config
8_EFI_Variable_Validation ‑ EFI_Variable_Validation
9_Kubernetes_Kernel_Config ‑ Kubernetes_Kernel_Config
…

♻️ This comment has been updated with latest results.

@qcomlnxci

Copy link
Copy Markdown

Test Coral run workflow

Test jobs for commit 81b82c7

  • qcomdistro: multimedia image
    Pass: 9 | Fail: 0 | Total: 9
  • qcomdistro: multimedia image-prop
    Pass: 41 | Fail: 0 | Total: 41

@mattface
Matt H (mattface) force-pushed the metadata-improvements branch 2 times, most recently from 0ad8374 to 908e505 Compare September 10, 2026 09:48
@mattface

Copy link
Copy Markdown
Contributor Author

Milosz Wasilewski (@mwasilew) I've added a bump to LAVA_TEST_PLANS_REF in here, so if you push this to next again, it should show actual metadata in the LAVA jobs. I can always remove that change for this to be merged here later.

@mwasilew

Copy link
Copy Markdown
Contributor

Something didn't work. This is one of the jobs from the next branch: https://lava.infra.foundries.io/scheduler/job/408251/definition#defline15. It only contains "old" metadata.

@mattface

Matt H (mattface) commented Sep 11, 2026

Copy link
Copy Markdown
Contributor Author

Something didn't work. This is one of the jobs from the next branch: https://lava.infra.foundries.io/scheduler/job/408251/definition#defline15. It only contains "old" metadata.

Previous version of the patch (the one you pushed to next already) didnt have the LAVA_TEST_PLANS_REF change, so no new metadata will have been added.

@mwasilew

Copy link
Copy Markdown
Contributor

@mwasilew

Copy link
Copy Markdown
Contributor

New version works as expected. Here is an example job: https://lava.infra.foundries.io/scheduler/job/414293/definition#defline15

 metadata:
  path: projects/meta-qcom/
  build-url:
    https://qli-prod-artifacts.qualcomm.com/qcom-prd-gh-artifacts/qualcomm-linux/meta-qcom/34614885753-1/
  pr-url: ''
  pr-number: ''
  gh-workflow-url:
    https://github.com/qualcomm-linux/meta-qcom/actions/runs/34614885753
  gh-workflow-run-id: '34614885753'
  gh-workflow-run-attempt: '1'
  build-type: PUSH
  build-run-id: '34614885753'
  source-repo: https://github.com/qualcomm-linux/meta-qcom
  source-branch: next
  source-sha: fd63d72a4ee826e1db199f3e963237220ec0b12a
  distro: nodistro
  build-config: nodistro
  testplan: nodistro/boot
  testkit-ref: testkit-2026.08.14
  lava-test-plans-ref: 2f2900cc3e7f2215ce7db6b5bf67955a0782ea31
  gh-workflow-name: Build on push
  image: core-image-base
  machine: iq-8275-evk
  kernel-recipe: linux-qcom-next
  kernel-version: 7.2+git
  kernel-release: 7.2.0-01462-gd49c33864d06
  kernel-repo: https://github.com/qualcomm-linux/kernel.git
  kernel-commit: d49c33864d06e9672dce57738be8851384578fcf

It needs to be confirmed whether this would work with PR as well.

@qcomlnxci

Copy link
Copy Markdown

Test Coral run workflow

Test jobs for commit 908e505

  • qcomdistro: multimedia image
    Pass: 9 | Fail: 0 | Total: 9
  • qcomdistro: multimedia image-prop
    Pass: 26 | Fail: 0 | Total: 26

@ricardosalveti

Copy link
Copy Markdown
Contributor

Some additional input form my little robot friend:

Fix before merge:

  • It breaks other repos' builds. meta-qcom-3rdparty and meta-qcom-arduino call meta-qcom's compile workflow from master (we can do this together or as a follow up, not really critical)
  • Failures are silently hidden. Values go into the INI variables file without escaping. A legal branch name containing %(x)s crashes lava-test-plans. The existing || true hides the crash, so that machine gets no LAVA jobs while the workflow stays green.

Wrong or inconsistent metadata:

  • Fork PRs get a mismatched source. The repo is always the base repo, but the branch and commit come from the fork. The event payload already carries the head repository.
  • Build type doesn't match S3 tags. Nightly and weekly runs both record SCHEDULE, while compile.yml tags the same builds NIGHTLY, WEEKLY or OTHER.
  • The multi-source kernel list never arrives. The action's jq filter keeps only strings and drops that list. That hides linux-yocto's second source on the dragonboard jobs.
  • Dragonboard jobs lack the build machine. They record the LAVA device name but not qcom-armv8a, so build paths can't be reconstructed.
  • Distro can be empty. Callers that don't pass the new input record an empty distro, even though it can be derived from an existing input.

Robustness and cleanup:

  • Warnings will pile up after rebase. The debug and performance builds deliberately skip the SBOM, so rebasing onto master adds 32 to 64 spurious warnings per scheduled run.
  • There is a simpler design. The script could print multi-line JSON that the action passes as a third variables file. That removes the jq conversion, the escaping crash and the dropped list. The review checked this against the pinned lava-test-plans.

Jobs recorded the build URL, pull request and workflow run, but not the
commit they were built from, the configuration under test, or the kernel
in the image, and none of it could be queried.

The source repository, commit, branch and build type are derived from the
event; the distro, build config, image, test plan and build machine the
action already knows; the kernel's recipe, repository, commit and release
are read from the SPDX SBOM every build already writes and passed over as
an artifact.

Everything is written as EXTRA_METADATA in JSON variables files passed
alongside the existing one, so recording a new key needs no change in
lava-test-plans. Bump the pinned lava-test-plans revision to one that
renders it.

Signed-off-by: Matt Hart <matthart@qti.qualcomm.com>
@mattface

Matt H (mattface) commented Sep 15, 2026

Copy link
Copy Markdown
Contributor Author

I believe I've covered all the comments, except I purposely chose to not parse out nightly/weekly for the build-type. Anyone who wants to, can do so from the gh-workflow-name metadata.

Other repos like 3rdparty/arduino will now quietly not create any new metadata until the script is introduced there.

@mattface
Matt H (mattface) marked this pull request as ready for review September 15, 2026 15:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants