Building a Dockerized Test Environment: Dameng / Highgo for QA

The real problem is not “can we install Dameng?”

In regulated and enterprise stacks, Dameng / Highgo / Kingbase show up as hard requirements. QA rarely fails because the database is mysterious — teams fail because the path to a working instance is tribal knowledge: bare-metal installers, missing packages, one-off VM snapshots, and “ask the DBA when he is free.”

That tax shows up before a single assertion runs. New hires burn a day on environment. CI flakes on DB boot. Automation authors hard-code credentials into scripts because nobody documented a reusable contract. If Postgres can be pull → run → connect, these databases should feel the same for testers.

This note is not a DBA handbook. It is the QA contract I optimized for: predictable tags, one service per container when possible, env-based credentials, and smoke connectivity before the full regression.

What the numbers say (live on this site)

Under the xuxuclassmate Docker Hub namespace I keep a QA-oriented suite. Homepage metrics refresh from the Docker Hub API Gateway — the same gateway dogfooded by README embeds — so these are not brochure numbers.

Dameng and Highgo dominate pull volume. That is the signal: teams reuse the painful databases first. Kingbase and TiDB matter for coverage, not vanity.

Design choices that kept pulls climbing

I treat image names and tags as a public API. Clever tag schemes break CI the week a suite graduates from a laptop to a pipeline. Boring wins.

• One primary service per image when possible — failed boots stay diagnosable
• Predictable tags over “latest-everything”; pin in CI, float only locally
• Docs travel with the image so newcomers do not hunt internal wikis
• Same mental model across Dameng / Highgo / Kingbase / TiDB: pull → run → connect
• Publish early enough that pull volume can invalidate the idea — or prove it

Minimal workflow that survives CI

Pick the database your suite actually asserts against. Expose the port your clients already expect. Put credentials in env files — never in committed test code. Smoke-connect before the full Playwright / API regression so DB boot failures fail in seconds, not after twenty minutes of UI noise.

• Local: compose file shared with the team, same ports as CI
• CI: pinned digest or immutable tag; cache pulls when your runner allows
• Secrets: CI variables / sealed secrets — never screenshot passwords into chat
• Ordering: DB healthy → migrate/seed if needed → API smoke → UI regression

                      # Pin a tag in CI — do not float on experiments
docker pull xuxuclassmate/dameng:<pinned-tag>
docker run -d --name qa-dameng \
  -p 5236:5236 \
  -e DM_PASSWORD=ChangeMe \
  xuxuclassmate/dameng:<pinned-tag>

# Fail fast: connectivity smoke before the full suite
# (JDBC / SQL client / health endpoint — whatever your image documents)

                    

Failure modes I keep seeing

Most “flaky database CI” stories are environment contracts, not assertion bugs. Fix the contract once and whole suites calm down.

• Floating tags: Friday green, Monday red because upstream rebuilt latest
• Shared containers: two jobs fight for the same port on a self-hosted runner
• Hidden hostnames: tests use localhost locally and a docker network name in CI without abstraction
• Giant all-in-one images: when boot fails you cannot tell which process died
• No smoke step: full UI suite becomes the database health check

How this feeds AI tools and agent skills

AI Test Case Generator and ClawHub skills look impressive in demos. They are worthless if the environment underneath cannot boot for the team that owns the product. Reusable DB images are the boring layer that makes multimodal generators and review loops honest.

The Docker Hub API Gateway exists for the same reason: README badges and this site’s homepage should read live pulls, not stale screenshots. Dogfooding the gateway keeps the proof honest.

Ship checklist before you call an image “ready for QA”

• A stranger can pull and run from the Docker Hub page without a private wiki
• Tag policy is written: what is pinned in CI vs experimental
• Credentials are env-driven; defaults are documented and non-production
• There is a one-command smoke connect path
• Pull counts are visible — if nobody pulls, you do not know if the pain was real