Travis CI is a cloud service. We can configure the build minimally via the web page (for example, a couple of environment variables and build triggers), and a few of us have access to the admin page. But that’s all.
Contrary to bamboo, which we host the server, agents, and we can install plugins.
We had this issue with Bahmni Core, and I had managed to make it temporarily go away by tweaking the Travis config. In particular by doing this:
mvn install -Dmaven.javadoc.skip=true -V -B -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
The Slf4jMavenTransferListener=warn would hide all the Maven ‘Downloading’ stuff.
But, eventually, it bit us again and builds started failing. The case of Bahmni Core is quite specific though.
But Core Apps goes beyond Maven output, it does all sort of things… This might be quite a chase.
So tell us. Why do we have such big build logs? What’s eating most of those logs?
Is it maven? Tests? Exceptions?
Without that, it’s hard to find a solution to create less log lines.
You can also run locally to find out.
@cintiadr , from these logs here, maven seems to consume the biggest part (Download logs) .And actualy the Maximum log length is exceeded before Travis attempting to run any single test.
So, one things we should probably do is to actually cache the m2 folder, the cache for maven, so it doesn’t have to download all dependencies on each build. Example.
You don’t seem to be doing that. You can try to run the tests in travis using ‘mvn -q’ for a few times, to download all dependencies to the cache, but I wouldn’t recommend you keep that flag as it suppress important errors.
You also want to have a ‘-B’ to your maven command.
i didnt get what you meant there
Travis is not configured to cache maven .m2 folder. That seems like a good idea to speed the build and avoid too many logs due to downloading all dependencies.
It has some side effects when handling snapshots, so you might want to use -U too.
did you mean i replace “mvn clean install” with “‘mvn -q’”
Btw @mozzy outside of the log length, I realise that this module has become a nightmare to build. Something must be wrong with its setup. All those npm related things are sneaking everywhere and make everything to take forever.
Thats very true @mksd, its really very hectic to build the core apps , it takes ages to build. any suggestions to solve that , could this be an issue to be tabled in the design call ??
wooow perfect. @cintiadr , i cached the logs , and added -q flag to the maven command , the logs were cached and and it ran perfect.
Here is the travis file , let me know if you have any issues with what i did , however much it solved the problem for now
language: java
jdk:
- openjdk8
addons:
firefox: "43.0"
cache:
directories:
- .autoconf
- $HOME/.m2
install:
- export DISPLAY=:99.0
- sh -e /etc/init.d/xvfb start
- tar -xjf /tmp/firefox-43.0.tar.bz2 --directory /tmp
- export PATH="/tmp/firefox:$PATH"
script: mvn clean install -q
see the build report
See full logs run locally
cc @k.joseph @dkayiwa @burke @dev4 @dev5 @dev3 @cintiadr @c.antwi
I would at the very least set up build profiles for the build, example here on AH in a different context. There should be a profile that does the usual (so the Java build) and a profile that does everything. Something along those lines, what the default profile does will also have to be determined.
For instance here even if you run -DskipTests, all those npm tests are run anyway, this is wrong.