Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support artifact uploads from lava jobs #15

Open
sjoerdsimons opened this issue Jan 13, 2023 · 0 comments
Open

Support artifact uploads from lava jobs #15

sjoerdsimons opened this issue Jan 13, 2023 · 0 comments

Comments

@sjoerdsimons
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant