Hi,
I have some test files stored in a private GIT repository. As I understand it there is no easy way to get the authentication passed through to the Test Definition, so I am looking for other options.
Is there a way that I can write the Test Definition to reference the files elsewhere?
I can bundle them into a tarball or zipfile and have them served via http without the need for authentication, but I cannot figure out how to describe this in the Test Definition.
Thanks.
Pete
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Fri, 4 Jan 2019 at 15:18, Pete Dyer Pete.Dyer@arm.com wrote:
Hi,
I have some test files stored in a private GIT repository. As I understand it there is no easy way to get the authentication passed through to the Test Definition, so I am looking for other options.
Is there a way that I can write the Test Definition to reference the files elsewhere?
LAVA supports parameters which can be passed to a test definition and visibility controls so that the values of those parameters are hidden from users who are not in the relevant Django group on that instance.
https://staging.validation.linaro.org/scheduler/job/246515/definition
https://master.lavasoftware.org/static/docs/v2/glossary.html#term-visibility
I can bundle them into a tarball or zipfile and have them served via http without the need for authentication, but I cannot figure out how to describe this in the Test Definition.
You will need to create a test definition script in a public repo which can use parameters specificed in the test job definition to access the private URL.
When this has been done in Linaro, the simplest option is to actually remove the download authentication from the scope of LAVA and handle it at the sysadmin level. Make all the arrangements that a nominated machine on the same network as the LAVA worker (or the worker itself) can have direct access to the private content and then use the LAVA visibility support to restrict the ability of users to submit test jobs which access that data or view the output of such test jobs. This makes things a lot easier to reproduce and therefore triage. Pre-authenticate the hardware - you'll have to use the visibility support to restrict the output anyway. This way, the authentication isn't leaked into the test job defnition, it's embedded into the infrastructure by the sysadmins.
Don't burden the test job with all of the authentication - let the test job behave as you would run the test job with the device on your desk and the authentication already complete - then restrict the access to the output.
This isn't about adding more hoops to get through, this is about being able to get useful data out of the automation in a way which can be reproduced by those who already have access to the restricted content to be able to debug the code.
lava-users@lists.lavasoftware.org