fix github actions build failure

[wind57]

[ryanjbaxter]

Thanks!

[wind57]

note for myself, things to do here:

• cache docker images via actions/upload-artifact@v2 and actions/download-artifact@v2
• check if a certain test phase does not run tests in every module
• why is the cache not re-used? It fails on a SocketTimeout about a certain junit-platform pom dependency, but shouldn't this one be part of the ~/m2 already? why is it trying to download it again?
• check if tests per job_instance are actually run (I already did that when I made the PR, but somehow the logs are misleading in this direction)

[wind57]

just found one more problem here with abstract classes... it is also present in circleci, so need to fix that also.

[wind57]

this gets funner and funner, it seems with 653 tests we are hitting this issue

[wind57]

I'm sorry for spamming with so many commits, but circleci test splitting does not have support for proper debugging, so this was my only hope. It seems that I have fixed the issue within circleci (I'll be sure when the build passes), after I confirm this I'll move to fix the github actions too.

[wind57]

@ryanjbaxter this is ready to review. thank you

[wind57]

I've merged latest main also.

[wind57]

My main concern is what needs to be done when we add a new integration test? What files need to be modified? Do certain things need to be in the POM? Seems like a README with details on how to structure the integration test and what other files need to be updated to ensure it runs properly would be good.

Actually you don't need to do anything, nada. :) just follow the convention of the other integration tests... But overall may be you are right, I'll add a README in this directory.

[wind57]

I am still in the blur what is going on here. The test indeed fails (ActuatorRefreshKafkaIT), for me locally too, so I started to debug it a bit. The test itself does a few things:

• starts configuration-watcher
• starts configuration-watcher-it (the test itself)
• starts an instance of kafka

So we start the application, then create a configmap with the same name and a proper label, this should trigger the informer (it does), in turn this will call applicationEventPublisher::publishEvent that is of type RefreshRemoteApplicationEvent (this happens too). In my understanding, at this point in time, I should see a message in springCloudBus topic, but when I have a lister:

bin/kafka-console-consumer.sh --topic springCloudBus --from-beginning --bootstrap-server localhost:9092

I don't see anything there. Weird. Still trying to figure out what is going on