can you show or what is not working for you? maybe we can help

I will check this approach on my machine but it would not solve the issue with system tests described earlier. If it works it partially solves the issue.

In order to run it directly with

use:

This will prefer the RPMs found in the ovirt-engine_master_build, also, if you would like to use different resources(i.e. vdsm and engine), create a configuration file, assuming it is 'extra-sources':

and run:

the "-s" parameter can accept any parameter that repoman accepts, it is quite flexible, have a look at: http://repoman.readthedocs.io, - tell me how it works for you.

- we have an open ticket for that https://ovirt-jira.atlassian.net/browse/OST-9 , though until it is completed - it should be fairly easy to run it locally by triggering the build_artifacts from the Jenkins job and passing the URL/or locally built RPMs to ./run_suite.sh.

we would value it also, but currently we don't have available resources to do it, its in the queue.
Until then, anyone should be able to run Lago + OST if needed on his machine without too much effort, and if documentation is missing or something isn't working please report it and we'll do our best to help.

I would value a jenkins job running ovirt-system-test with specific engine and vdsm hashes. Applications whose hashes are not specified should be taken from the default repository.

Hi , sorry for missing them, I'm closing the GitHub issue as this is the right place for it(OST).

You can run it with a custom repo in the following manner, in Lago directly:

the custom-source will be used first.
About passing it from run_suite.sh, I'll test and update.

I saw when running system testes that somehow it is not using the latest merged version.

On my machine I created custom repo with my changes and I pulled dependencies from ovirt repo for this specific version. I run the tests several times to make sure that my changes are not breaking anything. In between ovirt repo was updated with newest build which caused lago to pull it instead of my changes.

Both scenarios make lago/system tests unpredictable. I am do not know what I am testing and this leads to wrong assumptions.

I'm not sure what you mean, how the tests are unpredictable?
You can choose which suite you want to run (3.6/4.0/master) basic / hosted-engine - what exactly is unpredictable? can you elaborate?

Due to this issue I wasted time running lago on my host. We saw issues using system tests and this makes the tests unpredictable and without it in my opinion there is no value in running those tests since we do not know what is tested.

I think this is more of am ovirt-system-tests issue then a Lago issue, so not appropriate for Github.

please open in Lago github project if still relevant.
https://github.com/lago-project/lago/