I searched for an example job and found https://openqa.opensuse.org/tests/4457756#settings (scenario is https://openqa.opensuse.org/tests/latest?arch=s390x&distri=opensuse&flavor=agama-installer&machine=s390x-zVM-vswitch-l2&test=agama_default&version=agama-9.0).
The latest job is using the following settings:
ISO=agama-installer.s390x-9.0.0-openSUSE-Build17.9.iso
REPO_0=agama-installer.s390x-9.0.0-openSUSE-Build17.9
This will associate the file /var/lib/openqa/factory/iso/agama-installer.s390x-9.0.0-openSUSE-Build17.9.iso
and the file/directory /var/lib/openqa/factory/repo/agama-installer.s390x-9.0.0-openSUSE-Build17.9
with that job. The repo does not exist, though.
I suppose you wanted:
ISO=agama-installer.s390x-9.0.0-openSUSE-Build17.9.iso
REPO_0=agama-installer.s390x-9.0.0-openSUSE-Build17.9.iso
This way the repo points to an existing asset (the hardlink you want to preserve) and thus openQA will associate the asset with the job.
I had a look at the code and I don't think repo assets are treated in a special way. So you can have a single file as a repo asset and it will be associated with the job as usual.
To verify this I created a test job with the mentioned settings: https://openqa.opensuse.org/tests/4459707
The repo asset was correctly associated with the iso file/hardlink within the repo directory:
openqa=# select * from assets where id in (select asset_id from jobs_assets where job_id = 4459707);
id | type | name | t_created | t_updated | size | checksum | last_use_job_id | fixed
----------+-------+------------------------------------------------------------+----------------------------+----------------------------+-----------+----------+-----------------+-------
72605169 | iso | agama-installer.s390x-9.0.0-openSUSE-Build17.9.iso | 2024-09-04 21:33:11.128931 | 2024-09-04 21:33:11 | 558170112 | | 4457756 | f
72661737 | other | agama-installer.s390x-9.0.0-openSUSE-Build17.21.iso.sha256 | 2024-09-06 09:32:58.415696 | 2024-09-06 09:32:58 | 118 | | | f
72662202 | repo | agama-installer.s390x-9.0.0-openSUSE-Build17.9.iso | 2024-09-06 10:39:08.637938 | 2024-09-06 10:39:08.637938 | | | | f
(3 rows)
So the harlink will be preserved by the cleanup algorithm (as long as there is enough room in the job group the job is part of).
If you use the REPO_0
variable in your test code and it needs the .iso
extension removed you can do that in test code. That's better than lying openQA about the actual path of the asset.
Note that the size accounting is probably not going to work if the repo is a file/hardlink. However, I suppose this is actually in our favor here because we probably don't want to take the file size twice into account here.
One caveat of this is that the repo asset will not be cloned (because repo assets are generally not cloned) and features like the check for missing assets when restarting a job won't work (because repo assets are generally excluded from it).