For a case of local development setup, we export ../lava/lava_common
because the common understanding was that it contains schemas used to
validate test action paramters across LAVA server/dispatcher boundary
(so, even if we mostly work on dispatcher changes, if we e.g. add new
action params, we must propagate schema changes back to server, or job
submissions with new params will be rejected).
However, turns out that LAVA has a technical debt due to which some of
job schemas are duplicated in ../lava/lava_scheduler_app. Upstream issue
https://git.lavasoftware.org/lava/lava/issues/358. Until it's fixed
(and it even was closed as "not a priority right now"), we need to
duplicate most of the schema changes to ../lava/lava_scheduler_app,
and export it to the container.
For a case of local development setup, we export ../lava/lava_common because the common understanding was that it contains schemas used to validate test action paramters across LAVA server/dispatcher boundary (so, even if we mostly work on dispatcher changes, if we e.g. add new action params, we must propagate schema changes back to server, or job submissions with new params will be rejected).
However, turns out that LAVA has a technical debt due to which some of job schemas are duplicated in ../lava/lava_scheduler_app. Upstream issue https://git.lavasoftware.org/lava/lava/issues/358. Until it's fixed (and it even was closed as "not a priority right now"), we need to duplicate most of the schema changes to ../lava/lava_scheduler_app, and export it to the container.
Signed-off-by: Paul Sokolovsky paul.sokolovsky@linaro.org