W dniu 07.08.2012 12:16, Paul Sokolovsky pisze:
Hello,
On Tue, 07 Aug 2012 10:31:34 +0200 Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
[]
pfalcon: for something like -tests builds it would be perfect if we had a include feature, where one config can include some other (presumably 'base') config and just override something. It's not a strict requirement for implementing -tests builds sensibly but it would be an advantage, is that supported by any chance? (are those shell files I could just source with something like '. base.conf')
Build configs are no longer arbitrary shell scripts, they are validated to be of VAR=VAL format. As for include feature - do we have big enough configs to justify it being implemented on "native" build config level. Because there's other, and potentially more flexible approach - use separate script(s) to generate concrete config files out of arbitrary "bases" or "seeds". It can be adhoc and "optimized" - for example, in this specific case, you could have "base" (numbered N) configs and eng/test "mixins", totally N+2 files, from which you can generate concrete configs a-la "vector multiply". Compare that with maintaining N*3 configs in git with "include" approach.
More generally, to solve such usecases (bunch of similar builds with few params varying), there're "matrix builds" in Jenkins. We touched them few times in discussions over last year, but never actually got to play with them (and build frontend thus doesn't have support for them).
Thanks for the description of alternate possibilities and for describing what the current format is capable of.
I think the think we strive to achieve here is simplicity and easy of maintenance. I would say that we just either maintain N x 2 configs and don't do anything more elaborate (a fair assumption IMHO) or use a script to generate N x 2 configs from the base set of N configs.
Best regards ZK