Dear @accuminium,
this patch integrates on the shallow clone for the submodules included inside hero-gcc-toolchain.
Modifications
i. Add shallow clone for hero-gcc-toolchain when HERO_CI is set. (Fix #24)
ii. Clean after installation on every GCC build stage when HERO_CI is set.
Now is not anymore necessary to use any git submodule command from the root folder of hero-sdk. Everything is done within the builder script. When HERO_CI environmental variable is set the script clone the submodules shallowly otherwise it get them regularly.
Dear @accuminium, this patch integrates on the shallow clone for the submodules included inside
hero-gcc-toolchain
.Modifications
i. Add shallow clone for
hero-gcc-toolchain
whenHERO_CI
is set. (Fix #24) ii. Clean after installation on every GCC build stage whenHERO_CI
is set.Now is not anymore necessary to use any
git submodule
command from the root folder ofhero-sdk
. Everything is done within the builder script. WhenHERO_CI
environmental variable is set the script clone the submodules shallowly otherwise it get them regularly.I also added a new CI task on our Jenkins server that uses the Jenkins Pipeline. The pipeline controls all the builder targets one-by-one: https://iis-jenkins.ee.ethz.ch/view/hero-sdk/job/hero-sdk-pipeline/
Here the old CI task that control the
-A
build flow: https://iis-jenkins.ee.ethz.ch/view/hero-sdk/job/hero-sdk-centos7/I also tried to integrate such modifications on you
travis
branch to see if it fix the problem of memory footprint. Here the branch https://github.com/pulp-platform/hero-sdk/tree/travis-dev-integration.Here the build (still going) https://travis-ci.org/pulp-platform/hero-sdk/builds/441381805?utm_source=github_status&utm_medium=notification
I think, anyway, that travis at the moment is anyway too slow.