11 packages from benodiwal/testcontainers-ocaml at 0.1.1

[benodiwal]

This pull-request concerns:

• testcontainers.0.1.1: Docker containers for OCaml integration tests
• testcontainers-elasticsearch.0.1.1: Elasticsearch module for testcontainers
• testcontainers-kafka.0.1.1: Kafka module for testcontainers
• testcontainers-localstack.0.1.1: LocalStack module for testcontainers
• testcontainers-memcached.0.1.1: Memcached module for testcontainers
• testcontainers-mockserver.0.1.1: MockServer module for testcontainers
• testcontainers-mongo.0.1.1: MongoDB module for testcontainers
• testcontainers-mysql.0.1.1: MySQL module for testcontainers
• testcontainers-postgres.0.1.1: PostgreSQL module for testcontainers
• testcontainers-rabbitmq.0.1.1: RabbitMQ module for testcontainers
• testcontainers-redis.0.1.1: Redis module for testcontainers

---

• Homepage: https://github.com/benodiwal/testcontainers-ocaml
• Source repo: git+https://github.com/benodiwal/testcontainers-ocaml.git
• Bug tracker: https://github.com/benodiwal/testcontainers-ocaml/issues

---

🐫 Pull-request generated by opam-publish v2.7.1

[benodiwal]

The test failures are expected, this is a testcontainers library that requires Docker to run integration tests. OPAM CI environments don't have Docker available.
cc: @jmid

[jmid]

Thanks for the package and for the explanation!

I fully understand your POV (as a package maintainer myself) - it is a good idea to test such functionality 👍

From a opam-repo-maintainer POV, this is less desirable, because this means this collection of packages
are going to fail consistently on our CI when a dependency (dune, alcotest, ppx_lwt, ...) changes.
For example the last dune release in #29216 had 2332(!) failed jobs, which makes it hard to spot digression needles in that stack of red lights... 🪡 😮
As such, as a maintainer I'm reluctant to add 429 more failures on top for the next release...

Overall this is not an ideal situation - and other package authors are in a similar situation: #29166

Now, what can we do?

• as a first crude solution we could simply disable runtest in the opam packages (crude, simple to implement, will still let people install)
• alternatively, you could comment out those network/docker-requiring tests on the release branch (a bit more work, but retains some testing)
• as a third option, we can add x-ci-accept-failures: [...] entries to silence the failures (to be effective they will have to enumerate the fleet of platforms...)
• ...

[benodiwal]

Thanks for the guidance @jmid. I am going with the approach of maintaining the release in a separate branch opam-release and will handle tests in my repo ci on main branch.
The release is tracked here #29350. We can close this one.

[mseri]

Thanks