Document job-group defaults order of priority

We discovered that job-group variable definitions appear to
have higher precedence than project definitions. This caused a problem
for us in global-jjb as we would like to allow projects to override
default variables.

We should make it best practice that global-jjb stops providing
job-group definitions and deprecating any existing job groups.

Via patch I2b824e3cc89667698db8ebfdd3ce43f551e961d7 we were able to
resolve this for JJB version.

Change-Id: I93c8256193933a04e8732963216f69424cef3a5f
Signed-off-by: Thanh Ha <thanh.ha@linuxfoundation.org>

diff --git a/docs/best-practices.rst b/docs/best-practices.rst
index a9d4d20..fa78db5 100644 (file)
--- a/docs/best-practices.rst
+++ b/docs/best-practices.rst
@@ -337,12 +337,18 @@ variable. JJB will fill in whatever is in the defaults configuration.
 
 Variable expansion order of precedence seems to be:
 
-1. project section definition
-2. job-template variable definition
-3. defaults.yaml variable definition
+1. job-group section definition
+2. project section definition
+3. job-template variable definition
+4. defaults.yaml variable definition
 
 .. note:: Defaults set variables in job-templates and are NOT used in Macros.
 
+global-jjb should not provide job-group definitions and leave it up to users of
+global-jjb to create their own as a job-group as a variable defined in a job
+group the highest precendence. Global JJB should strive to be purely a
+job-template and macro library for downstream consumers.
+
 Final thoughts
 --------------