You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
for some lava tests it would be really nice to also attach artifacts; Think of e.g. seperate (bigger log files), image captures being made or really anything else that's not suitable to stick into just plain text output.
Lava does not have inbuild functionality for this; For reasonable reasons; The suggested solution in the lava documentation is to have a seperate service running and upload to it using curl with some token; Which is not a bad suggestion per se, but does require a seperate service while we already have gitlab being able to do artifact management :).
So a suggested solution for this would be to have the gitlab runner also be a http service that can receive such files, caches them locally while the job is running and when finishing pushes them into the general gitlab artifacts.
To both authenticate and identify which job an upload is for the runner could generate a random dynamic endpoint for each job to receive uploads which is only valid during a job run. This endpoint can be communicate to lava via the templating mechanism we already have available, leaving it up to job writer on how to cooperate this into the yaml job.
Implementation detail wise; we could simply integrate axum as a http server (to stay nicely in the hyper universe) and for simplicity we can assume there is a frontend server that does SSL termination so there is no need to manage ssl certificates. Similarly the base URL for where to reach a given runner should be provided by runner configuration.
The text was updated successfully, but these errors were encountered:
for some lava tests it would be really nice to also attach artifacts; Think of e.g. seperate (bigger log files), image captures being made or really anything else that's not suitable to stick into just plain text output.
Lava does not have inbuild functionality for this; For reasonable reasons; The suggested solution in the lava documentation is to have a seperate service running and upload to it using curl with some token; Which is not a bad suggestion per se, but does require a seperate service while we already have gitlab being able to do artifact management :).
So a suggested solution for this would be to have the gitlab runner also be a http service that can receive such files, caches them locally while the job is running and when finishing pushes them into the general gitlab artifacts.
To both authenticate and identify which job an upload is for the runner could generate a random dynamic endpoint for each job to receive uploads which is only valid during a job run. This endpoint can be communicate to lava via the templating mechanism we already have available, leaving it up to job writer on how to cooperate this into the yaml job.
Implementation detail wise; we could simply integrate axum as a http server (to stay nicely in the hyper universe) and for simplicity we can assume there is a frontend server that does SSL termination so there is no need to manage ssl certificates. Similarly the base URL for where to reach a given runner should be provided by runner configuration.
The text was updated successfully, but these errors were encountered: