Generator-jhipster: Some Daily Builds are Broken

[SudharakaP]

Overview of the issue

While working on another issue, I noticed that Infinispan builds are broken on our Daily Builds;

https://dev.azure.com/hipster-labs/jhipster-daily-builds/_build?definitionId=31

and

https://dev.azure.com/hipster-labs/jhipster-daily-builds/_build?definitionId=30

Motivation for or Use Case

Just to make the daily builds perfect. 🌠

Related issues

None that I know of.

Suggest a Fix

Currently unknown.

• [x] Checking this box is mandatory (this is just to show you read everything)

[pascalgrimaud]

cc @Hawkurane as he's the one who worked on JDL Daily Builds.

[Hawkurane]

When I did the scripts there might have been steps that I did not do that could have resulted in the build failing (e.g. changing the hosts file for keycloak).
If there wasn't anything particular that needed to be done compared to other builds then that means the generator is broken and needs to be fixed 🛠

[pascalgrimaud]

just cc the other ticket:

It seems that the Keycloak daily build has some problems with it's end-to-end tests phase.

https://dev.azure.com/hipster-labs/jhipster-daily-builds/_build?definitionId=34&_a=summary

In every build the e2e phase seems to be broken.

[Hawkurane]

Infinispan builds are bugged.
It looks like the gateway can't access the registry (totally unsure of what I'm saying) from what I'm seeing from the stack trace.

If anyone wants to work on this here is a jdl file to work from:

application {
 config {
   baseName store,
   applicationType gateway,
   packageName com.jhipster.demo.store,
   serviceDiscoveryType eureka,
   authenticationType jwt,
   prodDatabaseType mysql,
   cacheProvider infinispan,
   buildTool maven,
   clientFramework angularX,
   enableSwaggerCodegen true,
   testFrameworks [protractor]
 }
 entities *
}

application {
 config {
   baseName crm,
   applicationType microservice,
   packageName com.jhipster.demo.crm,
   serviceDiscoveryType eureka,
   authenticationType jwt,

   prodDatabaseType postgresql,
   buildTool maven,
   searchEngine elasticsearch,
   serverPort 8081,
   skipUserManagement true
 }
 entities * except Invoice, Shipment
}


entity Product {
   name String required
   description String
   price BigDecimal required min(0)
   size Size required
   image ImageBlob
}
enum Size {
   S, M, L, XL, XXL
}
entity Customer {
   firstName String required
   lastName String required
   gender Gender required
   email String required pattern(/^[^@\s]+@[^@\s]+\.[^@\s]+$/)
   phone String required
   addressLine1 String required
   addressLine2 String
   city String required
   country String required
}
enum Gender {
   MALE, FEMALE, OTHER
}
entity ProductOrder {
   placedDate Instant required
   status OrderStatus required
   code String required
   invoiceId String
}
enum OrderStatus {
   COMPLETED, PENDING, CANCELLED
}
entity OrderItem {
   quantity Integer required min(0)
   totalPrice BigDecimal required min(0)
   status OrderItemStatus required
}
enum OrderItemStatus {
   AVAILABLE, OUT_OF_STOCK, BACK_ORDER
}
relationship ManyToOne {
OrderItem{product(name) required} to Product
}
relationship OneToMany {
  Customer{order} to ProductOrder{customer(email) required},
  ProductOrder{orderItem} to OrderItem{order(code) required}
}

service Product, Customer, ProductOrder, OrderItem with serviceClass
paginate Product, Customer, ProductOrder, OrderItem with pagination

/* Entities for Invoice microservice */
entity Invoice {
   code String required
   date Instant required
   details String
   status InvoiceStatus required
   paymentMethod PaymentMethod required
   paymentDate Instant required
   paymentAmount BigDecimal required
}
enum InvoiceStatus {
   PAID, ISSUED, CANCELLED
}
entity Shipment {
   trackingCode String
   date Instant required
   details String
}
enum PaymentMethod {
   CREDIT_CARD, CASH_ON_DELIVERY, PAYPAL
}
relationship OneToMany {
   Invoice{shipment} to Shipment{invoice(code) required}
}
service Invoice, Shipment with serviceClass
paginate Invoice, Shipment with pagination
microservice Invoice, Shipment with accountancy
microservice Customer, Product, ProductOrder, OrderItem with crm

// will be created under 'docker-compose' folder
deployment {
   deploymentType docker-compose,
   appsFolders [store, crm],
   dockerRepositoryName "jeromepham"
   monitoring no,
   serviceDiscoveryType eureka
}

// will be created under 'kubernetes' folder
deployment {
   deploymentType kubernetes,
   appsFolders [store, crm]
   dockerRepositoryName "jeromepham",
   gatewayType zuul,
   monitoring no,
   serviceDiscoveryType eureka
   kubernetesNamespace jhipster,
   kubernetesServiceType LoadBalancer,
   istio false
}

[SudharakaP]

@Hawkurane : Thanks for the information. I'll give it a go this evening. 😄

[SudharakaP]

This seems to be failing on the sendCacheInformation call; I am trying to understand why; :thinking:

Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.infinispan.manager.DefaultCacheManager]: Factory method 'defaultCacheManager' threw exception; nested exception is org.springframework.beans.factory.BeanInitializationException: Cache (Infinispan protocol stack) configuration failed; nested exception is java.lang.NullPointerException at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185) at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:622) ... 170 common frames omitted Caused by: org.springframework.beans.factory.BeanInitializationException: Cache (Infinispan protocol stack) configuration failed; nested exception is java.lang.NullPointerException at com.jhipster.demo.store.config.CacheConfiguration.getTransportChannel(CacheConfiguration.java:277) at com.jhipster.demo.store.config.CacheConfiguration.lambda$globalConfiguration$1(CacheConfiguration.java:105) at org.infinispan.spring.starter.embedded.InfinispanEmbeddedAutoConfiguration.defaultCacheManager(InfinispanEmbeddedAutoConfiguration.java:71) at org.infinispan.spring.starter.embedded.InfinispanEmbeddedAutoConfiguration$$EnhancerBySpringCGLIB$$8435bba6.CGLIB$defaultCacheManager$0(<generated>) at org.infinispan.spring.starter.embedded.InfinispanEmbeddedAutoConfiguration$$EnhancerBySpringCGLIB$$8435bba6$$FastClassBySpringCGLIB$$70912937.invoke(<generated>) at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:363) at org.infinispan.spring.starter.embedded.InfinispanEmbeddedAutoConfiguration$$EnhancerBySpringCGLIB$$8435bba6.defaultCacheManager(<generated>) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) ... 171 common frames omitted Caused by: java.lang.NullPointerException: null at org.jgroups.protocols.Discovery.sendCacheInformation(Discovery.java:172) at com.jhipster.demo.store.config.CacheConfiguration.getTransportChannel(CacheConfiguration.java:244) ... 183 common frames omitted

cc : @srinivasa-vasu

[SudharakaP]

I've identified the problem with Infinispan builds and made a pull request above. It seems to me that when Infinispan is operating with a single node cluster (which is the configuration our Daily builds is using) it fails to correctly find the node. Let me know if you see any issues. :smile:

I'll try to see if I can fix the Keycloak builds next.

[SudharakaP]

As you might have seen our Infinispan builds are now successful in the MySQL side but there's still failures in the MariaDB side. So I've went ahead and made another PR which fixes that. :smile:

It seems to me from the docker-compose logs there's problems accessing MariaDB unless port 3306 is exposed as per https://github.com/openzipkin/docker-zipkin/issues/181. And indeed in my local this could be seen; once I opened this port the connection was always successful. :smile:

Although I did this as part of my investigations on this issue, I also think this will make all MariaDB builds more stable; as you see currently all MariaDB builds in our Daily Builds are flaky. :smile:

[SudharakaP]

I've made the final pull request to correct the remaining issue in the JDL file which we use for E2E tests. After this is merged, I believe the Keycloak daily builds should start working. :smile:

[SudharakaP]

Both of the issues mentioned in this thread has now been solved. We have successful Keycloak builds (https://dev.azure.com/hipster-labs/jhipster-daily-builds/_build/results?buildId=7242) and we have successful Infinispan builds as well (ex: https://dev.azure.com/hipster-labs/jhipster-daily-builds/_build?definitionId=31).

Therefore I am closing this issue. 😄

P.S: In some other builds there's some flakiness (Azure caching perhaps?) but I'll investigate these separately in the future. 😄

[Hawkurane]

Wow, thank you for your hard work !!

[pascalgrimaud]

@SudharakaP : thanks so much. I'm putting a bounty on this, as you fixed 3 or 4 bugs here. Plz claim it entirely ! It's really well deserved

[SudharakaP]

@Hawkurane : You are welcome. Now I think all builds are in working condition, but some builds I still see some flakiness; have to investigate some more on this later. :smile:

@pascalgrimaud : You are welcome; and thanks much for the bounty, that's very generous :smile:

[SudharakaP]

Bug bounty claimed at https://opencollective.com/generator-jhipster/expenses/1154