On 28 March 2017 at 12:46, Martin Sivak <msivak@redhat.com> wrote:

I have to be able to find all of them (including the tested directory) when I am checking which package version is available for OST for example. Nothing there is CI only, developers need all of them when bug is found by those systems and investigation is needed.

Guys, we need to know how CI works, what packages it consumes and how we can reproduce a test to be able to solve bugs found by CI.

This is a different request, and has nothing to do with the structure of resources.ovirt.org. The experimental flow can and does take packages directly from build artifacts jobs. It uses the 'repos/ovirt' directory as a composition space but that is just an aspect of the current implementation and will change. I agree we can do a better job of documenting how the experimental flow works.

I'm afraid the way the flow works currently does not allow for easy exact repoduction because the exact tested composition only exists in 'latest.under_test' for the duration of the test (Its not hard to tell which packages were tested mind you, but building a usable repo with those exact packages will take some work). But this is indeed something we might look at as a future tooling design goal.

I think that for most practical purposes, you probably don't need 100% exact reproduction. Running the manual OST job against the 'tested' repo (This is the default configuration for 'master' and can be selected for other releases), or running it locally, while adding a few extra packages via direct URLs in the extra_sources file probably allows reproducing most issues.

Barak Korren
bkorren@redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/