generator-jhipster: ngx-couchbase intermittent Test Failures

@SudharakaP Are you downgrading the couchbase java-client version? The dependency is already defined in jhipster bom project : see https://github.com/jhipster/jhipster/blob/master/jhipster-dependencies/pom.xml#L274 Current version defined is 2.7.9 : https://github.com/jhipster/jhipster/blob/master/jhipster-dependencies/pom.xml#L46

@vishal423 I try to upgrade to this version but it was not working…

@SudharakaP : the first run failed 😦

Ok, let’s close this. Plz @SudharakaP, claim the bounty, it’s well deserved !

I’m restarting it, as you need to see the result, right ?

I’m reopening this, and wait few days our daily builds before closing this definitely

Hello, sorry guys I couldn’t reproduce the problem on my end, I’ve updated Couchmove and Couchbase image version, but I don’t think it will change anything

@SudharakaP, I have noticed a few things while looking into this failure (maybe these can help):

1. Couchbase added Ubuntu 18.04 support in the v6.0.1. It would be good to try to upgrade the couchbase image (considering we already have 18.04 in our build infrastructure). I do see some couchbase image upgrade attempts by @DanielFran, but, not sure on why they were reverted.
2. Couchbase has recently released v6.0.3. We can try to see if that helps to improve the situation on this part.
3. Every time the build stalled, I have observed below message:

{“app_name”:“travisCouchbaseNoCache”,“app_port”:“-1”,“level”:“WARN”,“logger_name”:“c.c.c.c.e.Endpoint”,“message”:“[localhost:32775][KeyValueEndpoint]: Authentication Failure: Bucket not found on Select Bucket command”,“thread_name”:“cb-io-1-2”,“timestamp”:“2019-10-16T03:40:25.596Z”}

1. I believe test container support was tested with couchbase v5.5.1. I don’t see any change on that part, so, not very sure if that code will work flawlessly with the latest couchbase images.

@SudharakaP : do you want me to merge #10628, then restart the daily builds for OpenJDK8.Official ? Am I correct ?

Ok, restarting the Official.openjdk8 right now

Just tried tonight and I manage to reproduce the issue only 1 time. Then, in Azure Daily builds:

• with OpenJDK8, it’s KO -> https://dev.azure.com/hipster-labs/jhipster-daily-builds/_build/results?buildId=6338&view=logs&j=14ecf143-eece-5d03-88de-b4dd986b4ce4
• with OpenJDK11, it’s OK -> https://dev.azure.com/hipster-labs/jhipster-daily-builds/_build/results?buildId=6337&view=logs&j=14ecf143-eece-5d03-88de-b4dd986b4ce4

cc @tchlyah if you can help here For me, I gave up, as I’m not a Couchbase user

I’m reopening this, as we don’t have the real reason of the failures

See https://twitter.com/whichrich/status/1183348440803221504?s=19

I’ll priorize it and will investigate.

@pascalgrimaud : I’ve done three PRs. In the first two I’ve made OpenJDK 8 the default on Azure pipelines. Given our experience with Couchbase I don’t think the Azul JDK that ships with Azure can be trusted, and we should test everything with OpenJDK.

My third PR reintroduces Couchbase docker start. We’ll merge this and see how it goes. In the worst case we can just revert it back so that everything will work as usual 😄

yes, let’s try !

if I remember well, the problem with Couchbase was:

• if you started the Couchbase database with docker-compose file, then, launch backend tests, it will fail as testcontainer will use the same port and can’t start
• it’s not nice for the developer experience, but it was like this
• it was probably 1 year ago, when Couchbase support was introduced, I don’t know if it has been changed or not

I am not very sure on this solution. However, if it solves current issue, then, there is no harm to try this out.

@pascalgrimaud @vishal423 : I believe I found the problem here. It seems that the javadoc (via the maven javadoc plugin) runs on java 1.8.0_22; because we manually set JAVA_HOME in 00-init-env.sh. But notice that on Github Actions when Java 11 is installed (via the initial setup-java@v1) JAVA_HOME is already set to /opt/hostedtoolcache/Java/11.0.3/x64 and this value is overwritten by our 00-init-env.sh script and thus the javadoc ultimately uses the default java version installed in the build machine; which seems to be 1.8.0_22.

What we need to do is for GitHub CI not change the JAVA_HOME value. I’ve done some tests with this and it works. I will do this modification to the current PR soon. 😄

The best would be to test both: dev and prod But it would be too much configurations to test.

There are no specific reason, that couchbase is tested in prod profile. It could be in dev and Cassandra could be in prod

Thanks. I’m adding a bounty on this as it is important to be fixed quickly.