Integration-Tests: replace external systems with self-contained systems

[paullatzelsperger]

Integration tests should use self-contained systems (e.g. in a docker container) rather than actual cloud infrastructure. At the moment we have tests running against Azure CosmosDB and AWS S3. The following solutions should be looked into:

• CosmosDB Emulator: https://docs.microsoft.com/en-us/azure/cosmos-db/linux-emulator?tabs=ssl-netstd21
• AWS S3: https://hub.docker.com/r/minio/minio/

Lets make sure we're not violating any licenses etc. in the process :)

Linked to #246

377 contributes

Note: we want to create an E2E-Enviroment, where we actually deploy connector instances in the cloud, which could then indeed use the "real" cloud backends again. That is more of a long-term goal though.

[algattik]

Also Azurite for Azure storage

[paullatzelsperger]

has anyone ever actually used Azure CosmosDB Emulator in a Github Action? My problem is the following:

this guide instructs to export the certificate from the emulator. Since the certificate is different for every running container, we cannot check it in to VCS.

When I try to obtain the cert from localhost:8081 using the curl command, I get a OpenSSL SSL_connect: SSL_ERROR_SYSCALL error, but I cannot use the $ipaddr override, because environment variables for services cannot be set through bash commands.

When I try to just curl using $ipaddr (without setting the AZURE_COSMOS_EMULATOR_IP_ADDRESS_OVERRIDE) I get a connection-refused error.

I guess, what I'm asking is: has anyone a working Github Actions workflow I could "borrow" :)?

[paullatzelsperger]

Quick update: I was able to fix the connection error, turns out there needs to be a wait loop, since the docker image for CosmosDB does not have a health command. Next issue is related to Java Keystores though.

[paullatzelsperger]

Here's my thoughts about replacing a Azure-based CosmosDB with the Emulator for testing. Pros:

• does not incur cost with CosmosDB
• everyone can execute the tests locally without an azure subscription

Cons:

• No dedicated Github Action exists, only third-party ones that only work with Windows Runners.
• Only a (lightly documented) Docker image exists, docker container takes quite a bit of time to spin up
• no health cmd available, job needs to wait in a loop
• Self-signed certificate needs to be extracted from container, and stored in a temporary trust store.
• this has to be done every time, since the cert is always regenerated
• Since the number of vCPUs cannot be specified (some Kernel problem with the Github runner), the container runs pretty sluggish
• Due to that, we often get random failures and errors
• So far, I have not yet managed to get it to run on Github CI.

After a whole day spent with this topic, I think we should continue using the Azure-based CosmosDB. The Emulator seems not to be geared toward CI/CD, it's not easily integratable and will cause us headaches due to random failures. I therefore recommend skipping CosmosDB for this issue!

[ndr-brt]

Since #721 I think the cosmos db thing could be accomplished with some investigations. Will re-open this.

[ndr-brt]

I think this needs to stay open until we're able to run cosmos db tests in github actions. @algattik are you on this?

[algattik]

Yes I have something working already, will raise PR soon