Additional testcontainer migrations #551
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi @paulcwarren, I've migrated everything except GC, Elastic and Solr, I did want to get these done as well but my workload has exploded over the last couple of days and has limited my time considerably. Rather than holding off until I had completed things I've decided to open this PR in the interim.
I have added a Solr container and started to work on that but it occurred to me that the
paulcwarren/solr
(and possibly also thepaulcwarren/elasticsearch:7.6.2
) docker containers have specific set-up as the Solr test was failing with 404s on the URLs being used?Anyway, the Solr container is there and I've commented on where we could do any specific set-up you currently have in the
paulcwarren/solr
, maybe with this in place and swapping the Solr client out and the tests will just run? I'll be happy to complete the TC migration process but will definitely need input from you on whatever specific config you have in place in those custom docker containers.I also wanted to highlight something about the way I have done the test container implementations. Normally, there is no need to do things the way I have, all that is generally required is that we add an
@Rule
or@ClassRule
to the JUnit tests but this wouldn't work as theGinkgo4jSpringRunner
doesn't appear to call theTestRule.apply()
method on any rules added to tests. I did meant to mention this to you previously and forgot.Finally, I cleaned up a few bits of code, notable the scanning filters, they didn't appear to be working as the Spring autoconfiguration was still trying to instantiate connections to mongo when the tests were run. I have swapped those out for specific exclusions in the integration test
Application
classes and this does prevent the Spring autoconfig from kicking in.