Skip to content

qdl: support injecting overlays into the flashed rootfs - #86

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

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

Conversation

@mattface

Copy link
Copy Markdown

The qdl deploy method has no equivalent of the flasher method's 'overlay' image, so jobs using it cannot add extra files to the image they flash.

Instead, when overlays are requested, render a 'to: downloads' deploy action that patches the qdl flash tarball in a docker postprocess. The qdl deploy then flashes the patched tarball via downloads://, and apply-overlay still adds the LAVA test overlay on top.

The inputs the fastboot and nfs templates already accept are honoured here too: --overlay URL [PATH], OVERLAY_URL with OVERLAY_PATH, and AUDIO_CLIPS_URL. Jobs without overlays render exactly as before.

The qdl deploy method has no equivalent of the flasher method's 'overlay'
image, so jobs using it cannot add extra files to the image they flash.

Instead, when overlays are requested, render a 'to: downloads' deploy
action that patches the qdl flash tarball in a docker postprocess.
The qdl deploy then flashes the patched tarball via downloads://, and
apply-overlay still adds the LAVA test overlay on top.

The inputs the fastboot and nfs templates already accept are honoured
here too: --overlay URL [PATH], OVERLAY_URL with OVERLAY_PATH, and
AUDIO_CLIPS_URL. Jobs without overlays render exactly as before.

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I think it might be easier to add overlay support in deploy-to-qdl in LAVA. This patch adds a lot of complexity.

url: '{{ url }}'
{% if overlay_use_download_headers %}
headers:
{{ AUTH_HEADER_NAME }}: {{ AUTH_HEADER_TOKEN }}

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

This should work in theory, but we might expect arifacts stored in different bucket using different tokens. Should the header/token be part of the overlay structure (name,url,dst,header,token_name)?

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