Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Automated tests - Circle CI #2

Closed
rnorth opened this issue Apr 26, 2015 · 6 comments
Closed

Automated tests - Circle CI #2

rnorth opened this issue Apr 26, 2015 · 6 comments
Labels
help wanted

Comments

@rnorth
Copy link
Member

rnorth commented Apr 26, 2015

If possible, use Travis, although use of docker will probably make this complex...
@swissarmykirpan
Copy link
Member

CircleCI is the way to go as discussed. Do you want me to pick this up? @rnorth

@rnorth
Copy link
Member Author

rnorth commented Jun 26, 2015

Yes please, but can we talk about it later today (my time) / tomorrow (your
time)?

On Fri, Jun 26, 2015 at 9:18 AM, gusohal notifications@github.com wrote:

CircleCI is the way to go as discussed. Do you want me to pick this up?
@rnorth https://github.com/rnorth

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

@swissarmykirpan
Copy link
Member

Sure

@rnorth rnorth mentioned this issue Jun 28, 2015
Closed
@rnorth rnorth changed the title Automated tests - Travis? Automated tests - Circle CI Jul 8, 2015
@rnorth
Copy link
Member Author

rnorth commented Jul 8, 2015

I started playing around with this on a branch (circle-ci) but it's a little more complicated than first meets the eye - because we need to connect to the docker daemon via tcp, and that entails getting TLS set up.

This article (in German) seems to address exactly this scenario, so will probably be quite useful:

http://www.heise.de/developer/artikel/Abgesichert-Docker-auf-CircleCI-mit-TLS-ausfuehren-2574058.html

@swissarmykirpan
Copy link
Member

Oooh fun!

@rnorth
Copy link
Member Author

rnorth commented Jul 9, 2015

Now closed in df0f41b

@rnorth rnorth closed this as completed Jul 9, 2015
@VladoDemcak VladoDemcak mentioned this issue Dec 14, 2017
Closed
bsideup pushed a commit that referenced this issue Jul 25, 2018
@rnorth
Merge pull request #2 from testcontainers/spring-boot-example
fc74c90 
Add Spring Boot example of usage
@bsideup bsideup mentioned this issue Mar 27, 2019
Closed
beargiles pushed a commit to beargiles/testcontainers-java that referenced this issue Dec 14, 2019
@beargiles-snaplogic
[Issue-2179] Add JDBC binding to Cassandra module
3c6ec94 
Many enterprise environments require a JDBC connection to Cassandra for
integration into legacy systems. This patch changes the parent of the
CassandraContainer to JdbcDatabaseContainer and optionally allows enables
the 'native api' (thrift-over-rcp) used by many JDBC driver implementations.

A new test was added - testCassandraJdbcQuery().

== Status

This code isn't ready for merge - it's being offered for review. It
loosely corresponds to my work on Friday creating a local fork that
integrates into our existing environment where we were already using
JDBC connections to Cassandra servers. That fork works so I know this
fork is very close to working. Of particular note is the log line

```
INFO  [main] 2019-12-14 21:31:33,520 ThriftServer.java:116 - Binding thrift service to /0.0.0.0:9160
```

since that indicates that the server is listening to the RPC port
required by the JDBC driver.

== Remaining Work testcontainers#1

The connection attempt fails with

```
Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: localhost/127.0.0.1:32862 (com.datastax.driver.core.exceptions.TransportException: [localhost/127.0.0.1:32862] Channel has been closed))
    at com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:268)
    at com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:107)
    at com.datastax.driver.core.Cluster$Manager.negotiateProtocolVersionAndConnect(Cluster.java:1813)
    at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1726)
    at com.datastax.driver.core.Cluster.init(Cluster.java:214)
    at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:387)
    at com.datastax.driver.core.Cluster.connect(Cluster.java:338)
    at com.github.adejanovski.cassandra.jdbc.SessionHolder.createSession(SessionHolder.java:201)
    ... 36 more
```

however I know that the same JDBC driver works elsewhere. It may be something as simple as a missing datastax jar.

== Remaining Work testcontainers#2

The test includes calls to `cassandraContainer.setWaitStrategy()`. Neither seems to have any effect.
In the other fork I only saw a wait strategy used was when I explicitly set the waitStrategy
value in the constructor.
kiview pushed a commit that referenced this issue Jan 11, 2022
@codepitbull
Merge pull request #2 from hivemq/docs
47d2b1e 
First iteration of public docs
@wu-sheng wu-sheng mentioned this issue Nov 16, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rnorth @swissarmykirpan