Skip to content

Meta qcom build provenance - #97

Closed
Matt H (mattface) wants to merge 3 commits into
masterfrom
meta-qcom-build-provenance
Closed

Matt H (mattface) wants to merge 3 commits into
masterfrom
meta-qcom-build-provenance

Conversation

@mattface

Copy link
Copy Markdown

Part 1 of a series of metadata expansions to meta-qcom and other projects that use lava-test-plans

@@ -1,4 +1,16 @@
build-url: {{BUILD_URL | default('')}}
build-type: {{BUILD_TYPE | default('')}}
build-run-id: {{BUILD_RUN_ID | default('')}}

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

since we're running this exclusively in github at the moment, what is the difference between build-run-id and gh-workflow-run-id? Aren't these redundant?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

No, they are different inside pull requests, for example compare the gh-workflow-run-id on this job https://lava.infra.foundries.io/scheduler/job/406624/definition#defline23 with the build-url

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

They're different because build-id will not be available in the test workflow for PR.

Record the commit under test and the build configuration - machine,
distro, kernel, image, test plan and the refs the job was generated
from - alongside the existing build and pull request URLs. LAVA indexes
the metadata and filters on it, so these become keys jobs can be
selected by.

Every new key defaults to empty, so callers that do not set them render
as before.

Signed-off-by: Matt Hart <matthart@qti.qualcomm.com>
meta-qcom-3rdparty and the qcom-distro variant of meta-qcom each kept a
byte-identical copy of the metadata template, so a key added to one
silently skipped the others. meta-qcom-distro already symlinks its copy;
do the same for the remaining two.

meta-qcom-3rdparty jobs now render the provenance keys, empty until its
own workflow sets them. flit dereferences symlinks when building the
wheel, so installs are unaffected.

Signed-off-by: Matt Hart <matthart@qti.qualcomm.com>
The metadata templates render the commit under test and the build
configuration, but the action never set the variables behind them, so
they came out empty for every caller.

Fill them in. Only the source commit, its branch and the kind of build
need new inputs: the machine, distro, kernel, image, test plan and both
revisions are already known to the action.

Signed-off-by: Matt Hart <matthart@qti.qualcomm.com>
@mattface
Matt H (mattface) force-pushed the meta-qcom-build-provenance branch from 8a78e02 to 3e32408 Compare September 9, 2026 17:10
@mattface
Matt H (mattface) marked this pull request as draft September 9, 2026 21:17
@mattface

Copy link
Copy Markdown
Author

scrapping this because functionality is replaced by EXTRA_METADATA

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.

2 participants