testcontainers / testcontainers-c Goto Github PK

When using CGO, structures like this one are generated:

/* Return type for RunContainer */
struct RunContainer_return {
	GoInt r0; /* id */
	char* r1; /* errstr */
};
extern struct RunContainer_return RunContainer(GoInt requestID);

/* Return type for GetURI */
struct GetURI_return {
	GoString r0; /* uri */
	GoInterface r1; /* e */
};

Maybe CGO could be tweaked or configured to inject proper field names to improve DevX

Wishlist

This is how we want to see the code once everything is done, maybe:

#include <stdio.h>
#include <string.h>
#include "testcontainers-c.h"
#include "testcontainers-c-wiremock.h"

#define DEFAULT_IMAGE "wiremock/wiremock:3.1.0-1"

int main() {
    printf("Using WireMock with the Testcontainers C binding:\n");

    printf("Creating new container: %s\n", DEFAULT_IMAGE);
    int requestId = NewContainerRequest(DEFAULT_IMAGE);
    WithExposedTcpPort(requestId, 8080);
    WithWaitForHttp(requestId, 8080, "/__admin/mappings");
    WithFile(requestId, "test_data/hello.json", "/home/wiremock/mappings/hello.json");
    struct TestContainer container = RunContainer(requestId);
    if (container.Id == -1) {
        printf("Failed to run the container: %s\n", container.errorMsg);
        return -1;
    }

    printf("Sending HTTP request to the container\n");
    struct HttpGetResponse response = SendHttpGet(container.Id, 8080, "/hello");
    if (response.code == -1) {
        printf("Failed to send HTTP request: %s\n", response.errorMsg);
        return -1;
    }
    if (response.code != 200) {
        printf("Request failed: HTTP-%d\n%s\n", response.code, response.errorMsg);
        return -1;
    }
    printf("Server Response: HTTP-%d\n%s\n\n", response.code, response.msg);
    return 0;
}

Currently a lot of GString / GInt are used. It would be nice to switch to basic types so that API is easier to use. Golang code is highly customized anyway

The Dev Container images currently uses the Python base image and does not allow for building the project itself. It would be nice to add it so that we have portable developer environment for the project.

• Add all necessary packages, ideally update the toolchain mentioned in CONTRIBUTING
• Update the .devcontainer README
• Update the ci workflow on GitHub actions so that it uses Dev Container (see the example on the site)
• Update the contributor guide to use the Dev Container

It would be great to have a CppUnit Demo showcasing integration of the library, with automatic teardown of the container

Once we generate testcontainers-c.h, we can use Doxygen to build code documentation in the documentation pipeline. It is unlikely to be trivial, because not all data is propagated to header files. Waybe CGO could be tweaked to inject more information

References

• https://www.doxygen.nl/
• https://github.com/marketplace/actions/doxygen-action
• https://pkg.go.dev/cmd/cgo

Currently we have a CTest test suite inside the code, and it is a good start for tests. At the same time, it would be nice to have another example that uses the code as an external package in the examples

Due to the reasons unknown, the file does not get loaded by WireMock even if it is added to the container according to the log.
tc_with_file() works well. One has to inspect the container I guess, all diagnostic methods, while cool to add, didn't particularly help

It is not there yet :(

The current C API is quite complicated for consumption. It would be great to have a C++ binding with

• Namespace
• Proper Structures
• TBD: Classes

It would be nice to initialize the documentation structure, published to GitHub Pages

• Overview
• Quickstart
• Feature docs
• Placeholder for Doxygen-generated code docs

Currently, the style of the site is different from other components. It would be nice to copy the existing style of the Testcontainers for Golang, including the CSS, Markdown settings and library components

As @kiview wrote:

Yes, the whole mkdocs setup is OSS:
https://github.com/testcontainers/testcontainers-go/blob/main/mkdocs.yml

We use Testcontainers Go under the hood. It would be nice to extend the wrapper API

Scope

Each is likely a separate pull request or EPIC on its own

• Logging management and streaming
• Network management
• API Management
• Docker Client management
• Docker Compose API for multi-container deployments

References

• https://golang.testcontainers.org/

If I try to run a RabbitMq image using the testcontainers-c library, it does not run and exits with the following error:

/usr/local/bin/docker-entrypoint.sh: line 50: exec: : not found

Here is the C code I used to try launching the container:

#include <stdio.h>
#include <unistd.h>
#include "testcontainers-c.h"

#define RABBITMQ_IMAGE "rabbitmq:3.12.11-management-alpine"
int main() {
    printf("Using RabbitMq with the Testcontainers C binding:\n");

    printf("Creating new container: %s\n", RABBITMQ_IMAGE);
    int requestId = tc_new_container_request(RABBITMQ_IMAGE);
    tc_with_exposed_tcp_port(requestId, 5672);
    tc_with_exposed_tcp_port(requestId, 15672);
    struct tc_run_container_return ret = tc_run_container(requestId);
    int containerId = ret.r0;
    if (!ret.r1) {
        printf("Failed to run the container: %s\n", ret.r2);
        return -1;
    }
    printf("Launched container with ID: %d\n", containerId);

    sleep(5);
    char * logs = tc_get_container_log(containerId);
    printf("Received logs: %s\n", logs);

    return 0;
}

Would this be a problem of the testcontainers-go library, or perhaps how its being invoked? It would be nice to be able to use the C library to run a RabbitMQ image to run tests.

Also, here is the output of the C program above when running it on my machine (openSUSE Leap 15.6 host):

Using RabbitMq with the Testcontainers C binding:
Creating new container: rabbitmq:3.12.11-management-alpine
2024/07/09 14:37:52 github.com/testcontainers/testcontainers-go - Connected to docker: 
  Server Version: 24.0.7-ce
  API Version: 1.43
  Operating System: openSUSE Leap 15.6
  Total Memory: 64013 MB
2024/07/09 14:37:52 🐳 Creating container for image docker.io/testcontainers/ryuk:0.5.1
2024/07/09 14:37:52 ✅ Container created: 9c5655466cbe
2024/07/09 14:37:52 🐳 Starting container: 9c5655466cbe
2024/07/09 14:37:52 ✅ Container started: 9c5655466cbe
2024/07/09 14:37:52 🚧 Waiting for container id 9c5655466cbe image: docker.io/testcontainers/ryuk:0.5.1. Waiting for: &{Port:8080/tcp timeout:<nil> PollInterval:100ms}
2024/07/09 14:37:52 🐳 Creating container for image rabbitmq:3.12.11-management-alpine
2024/07/09 14:37:52 ✅ Container created: ffe15b2ab23c
2024/07/09 14:37:52 🐳 Starting container: ffe15b2ab23c
2024/07/09 14:37:53 ✅ Container started: ffe15b2ab23c
Launched container with ID: 0
Received logs: /usr/local/bin/docker-entrypoint.sh: line 50: exec: : not found

It would be nice to publish the Testcontainers packages to Conan

• Add package and build definitions
• Register the package on vcpkg
• Add publishing to GitHub Actions

References

• https://conan.io/
• #2

It would be nice to publish the Testcontainers packages to vcpkg

• Add package and build definitions
• Register the package on vcpkg
• Add publishing to GitHub Actions

References

• https://vcpkg.io/en/

I consider changing the project name. Should it be "Testcontainers for C/C++"? Or would it make sense to make it "Testcontainers Native" or another more generic name, and keep the "Testcontainers for C/C++ " for binding libraries which are likely to be many if the project keeps evolving? Any feedback is welcome!

As the roadmap states, In the future, I want the project to have proper C++ bindings, and I guess the Swift ones would find users too. Same for other advanced cases like MATLAB, and other languages that can include native shared libraries (E.g. R/Delphi/Perl and many others).

Testcontainers reach as a native binding

Since I am working on WireMock, I want to have it as a first PoC module for the implementation. The module would provide additional APIs for management, etc