On 28 March 2017 at 12:46, Martin Sivak <msivak(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/