GreptimeDB Dev Docker Image

Environment State

The image configuration lives only in the selected workspace's .env. The collector reads only the following keys and never reads or displays other .env values:

IMAGE_REGISTRY=registry.example.com/team
IMAGE_REPOSITORY=greptimedb-dev
IMAGE_TAG=dev-001

1. Read .env if it exists. Ignore blank lines and # comments.
2. Show the discovered registry, repository, and proposed tag to the user.
3. Include registry/repository and tag in the batch configuration even when values already exist; saved values are defaults, not authorization to reuse them.
4. Compare the selected configuration with the three current managed values. If all match, skip .env confirmation and do not update the file. Otherwise, preview only the changed IMAGE_* values, request confirmation, and update the file while preserving unrelated entries and comments.
5. Never put registry credentials, access tokens, passwords, or docker login output in .env, build commands, logs, or responses. Ask the user to log in themselves if a push needs authentication.

For a repeated build, offer an incremented tag before asking. Use scripts/next_image_tag.py --tag <existing-tag> to calculate it. It increments the final numeric component while preserving zero padding:

weny-2025-0715-01 -> weny-2025-0715-02
v0.1.4 -> v0.1.5
debug-009 -> debug-010

If the saved tag has no trailing number, ask the user for the next tag rather than inventing a versioning convention. Do not overwrite an existing image tag without explicit user confirmation.

Only if a managed value is missing or differs, persist the values with the bundled helper after confirmation instead of hand-editing the file:

python3 <skill-dir>/scripts/update_image_env.py \
  --env <source-checkout>/.env \
  --registry <registry> \
  --repository <repository> \
  --tag <tag>

Build Procedure

1. Inspect the host and container tooling

Run these checks and report the selected path:

uname -s
uname -m
docker version --format '{{.Server.Os}}/{{.Server.Arch}}'
docker buildx version
docker buildx inspect --bootstrap

For a native-platform build, Podman can be used if Docker is unavailable. For any non-native request, require Docker Buildx. Do not silently fall back to a native build when the requested image platform differs.

If the requested target is unavailable, stop and ask the user to configure a Buildx builder and cross-compilation toolchain externally. Do not automate privileged QEMU or binfmt setup, and never run an unpinned privileged image.

2. Build the executable for the image platform

From the source checkout, build the requested binary. For open-source amd64:

<skill-dir>/scripts/build_binary.sh \
  --source <source-checkout> --package cmd --bin greptime --profile nightly

For open-source arm64:

<skill-dir>/scripts/build_binary.sh \
  --source <source-checkout> \
  --package cmd \
  --bin greptime \
  --profile nightly \
  --target aarch64-unknown-linux-gnu

For Enterprise, use the user-provided executable target, for example:

<skill-dir>/scripts/build_binary.sh \
  --source <source-checkout> --bin greptime-ent-cloud --profile nightly

For a user-selected profile, replace nightly in the helper call and resolve the binary under target/<profile>/<binary> (or target/<rust-target>/<profile>/<binary> for cross-compilation). Reuse the existing target file only when the interactive profile question selected reuse; otherwise invoke the helper to rebuild it.

Do not use a binary compiled for the host architecture in an image intended for another architecture. Determine the binary path from the Cargo target and profile, then copy it into the Docker context as greptime:

cp <source-target-binary> <build-context>/greptime

Verify it before building the image with file <build-context>/greptime; its reported architecture must match the requested target platform.

Create a fresh isolated build context (never use the repository root) and use the bundled preparation script. The helper rejects an existing Dockerfile or binary output to prevent accidental context reuse:

<skill-dir>/scripts/prepare_context.sh \
  --context "$(mktemp -d)" \
  --binary <source-target-binary> \
  --dockerfile <skill-dir>/assets/Dockerfile \
  --platform <platform>

3. Build or push the image

Run the command only after the user confirms the final image reference and whether it should be pushed.

Use the bundled build helper rather than spelling out individual Docker or Podman commands. It follows the existing scripts' Docker-first/Podman-fallback behavior, uses Buildx for a non-native Docker request, and accepts exactly one target platform per image:

<skill-dir>/scripts/build_image.sh \
  --context <build-context> \
  --image <image-reference> \
  --platform <platform> \
  --mode local|push

--mode local builds a native image locally or uses docker buildx --load for a non-native image. --mode push pushes the selected single-platform image. The helper never pushes in local mode.

This is intentionally a runtime image built from a precompiled binary, not a multi-stage Dockerfile. Ubuntu 24.04 is the runtime base image only; select one target platform separately as linux/amd64 or linux/arm64. Only introduce a multi-stage Dockerfile if the user asks to compile within Docker or the local Rust toolchain cannot build the required target. Keep the final Ubuntu 24.04 runtime stage and existing entrypoint unless the user asks to change runtime behavior.

At the final confirmation, repeat that the selected reference is a development/local-cluster test image, not a release artifact. If the user requests a release or production image, stop and direct them to the release process instead.

4. Verify the result

For a local image, use the selected engine to inspect its architecture and start it with --help:

docker image inspect <image-reference> --format '{{.Os}}/{{.Architecture}}'
docker run --rm <image-reference> --help

For Podman, use podman image inspect <image-reference> and podman run --rm <image-reference> --help. For a pushed Podman image, use podman manifest inspect <image-reference>.

For a pushed image, inspect its remote manifest:

docker buildx imagetools inspect <image-reference>

Report the final image reference, target platform, source binary path, and whether the image was loaded locally or pushed.

Safety Rules

• This skill is only for development and local-cluster testing. Never present its image as a production, release, or officially published artifact.
• Never push by default. Local debug builds should use a local tag and load the image unless the user explicitly requests a push.
• Do not run docker login, privileged QEMU setup, package installation, or overwrite a tag without confirmation.
• Do not delete existing images, builders, binaries, or .env entries as part of this workflow.
• Stop and explain if Docker's server is unavailable, Buildx cannot support the requested platform, or the copied binary architecture does not match the image platform.