W dniu 07.08.2012 10:30, Zygmunt Krynicki pisze:
CCing the mailing list.
Hello
In accordance with blueprint: eng-and-test-builds [1]
To implement the final work item of my blueprint I'd have to manually create (and later keep in sync) of the following configurations.
https://android-build.linaro.org/builds/~linaro-android/vexpress-ics-gcc47-a...
https://android-build.linaro.org/builds/~linaro-android/vexpress-rtsm-ics-gc...
https://android-build.linaro.org/builds/~linaro-android/origen-ics-gcc47-sam...
https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc46-i...
https://android-build.linaro.org/builds/~linaro-android/snowball-ics-gcc47-i...
https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc47-tilt...
https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc44-kwg-...
https://android-build.linaro.org/builds/~linaro-android/panda-ics-gcc47-omap...
https://android-build.linaro.org/builds/~linaro-android/vexpress-jb-gcc47-ar...
https://android-build.linaro.org/builds/~linaro-android/origen-jb-gcc47-sams...
https://android-build.linaro.org/builds/~linaro-android/snowball-jb-gcc47-ig...
https://android-build.linaro.org/builds/~linaro-android/panda-jb-gcc47-tilt-...
https://android-build.linaro.org/builds/~linaro-android/panda-jb-gcc47-tilt-...
https://android-build.linaro.org/builds/~linaro-android/galaxynexus-jb-gcc47...
This screams as insane in my head so I went looking and recalled that Infrastructure has implemented feature where we can keep the configs in git. That would dramatically simplify everything.
So, with that in context I'd like to propose three options and I'd like to ask you to pick the one you'd like to see implemented now:
- Ignore git configs, duplicate everything manually and later check if
it changes once a week to update -tests builds.
- Create -tests builds manually but pull the configs from git. We still
need to keep them in sync manually (with the base configs) but at least updates are easy to manage (one commit instead of a messy edit-and-save on dozen pages)
- Move all existing configs to git, have a flag day, move all builds to
git. Derive -tests builds from -eng builds. This is by far the most 'lazy' solution (as in I'm too lazy to do all the manual work all the time in the future) but has the most risk.
pfefferz, asac: please decide and let me know
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')
Best regards ZK
[1] https://blueprints.launchpad.net/linaro-android/+spec/eng-and-test-builds
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).
Best regards ZK
[1] https://blueprints.launchpad.net/linaro-android/+spec/eng-and-test-builds
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
linaro-android@lists.linaro.org
-
Paul Sokolovsky -
Zygmunt Krynicki