Repository navigation
Refs #136: Add a stabilisation period for the launched Virtuoso container - #138
Conversation
rnorth
changed the title
… container, as it seems newer versions of the base container are responding OK to the first 'SELECT 1' but then rejecting the subsequent query. Lock down Virtuoso containers to a fixed tag rather than latest, unless specified. Reduce verbosity of logs for Virtuoso tests. Add fixed Virtuoso version to JDBC test Update to latest version of duct-tape to allow use of fixed Inconsistents get Reinstate virtuoso maven module
|
I think these changes should fix the problem, but now a new issue on CI: If this third party maven repo stays down I think the Virtuoso module may have to take a pass on the next release :( In the slightly longer term I'd like to try and decouple this dependency to avoid issues like this in the future. Not sure what the options are yet, though... |
…hat it relies on a third party maven repository. This allows developer testing if the Virtuoso drivers are available, but does not couple CI to the availability of the drivers.
|
@v-schulz would you mind having a look at this and checking you're happy with the changes? I've put the Virtuoso module under the As-is, the Virtuoso module is not validated by CI, just by local developer builds when running What do you think? |
|
I think that's ok - especially because Virtuoso may not be the most important TestContainer available . Whoever wants to use it can easily activate the module. I didn't find a solution to the problem, neither, so we can stick to this. |
|
@v-schulz thanks - I'll merge then! FWIW it's basically just excluded from CI - it will still be published as a maven module so won't be hard to use for people who need it. |
… as it seems newer versions of the base container are responding OK to the first 'SELECT 1' but then rejecting the subsequent query.
Lock down Virtuoso containers to a fixed tag rather than latest, unless specified.
Reduce verbosity of logs for Virtuoso tests.