Skip to content

Add docker-test skill for running commands in arcticdb Docker container #2947

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
G-D-Petrov wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Add docker-test skill for running commands in arcticdb Docker container #2947

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
02894e7
Add docker-test skill for running commands in arcticdb Docker container
G-D-Petrov Mar 4, 2026
5b55612
feat: Enhance docker-test skill with named container support and clea…
G-D-Petrov Mar 4, 2026
a3aa2de
Address Pr coments
G-D-Petrov Mar 4, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions .claude/skills/docker-test/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
---
name: docker-test
description: Run commands or tests inside the arcticdb Docker container
argument-hint: "[command]"
---

Run commands or tests inside the arcticdb Docker container.

Copy link
Copy Markdown
Contributor

@claude claude Bot Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No mention of what the Docker image actually provides / prerequisites

The Usage section jumps straight to example invocations without explaining what environment the container provides (Python version, whether ArcticDB is pre-installed or needs to be built, etc.). A developer encountering this skill for the first time won't know whether they need to build ArcticDB into the image first or whether import arcticdb will work out of the box.

Adding a brief note like "The image is a build environment — ArcticDB must be installed into it (e.g. by running pip install -ve . inside the container) before running tests" would significantly improve usability.

## Usage

- `/docker-test` — start the container if not running, then open an interactive prompt for what to run
- `/docker-test pytest python/tests/unit/some_test.py` — run a specific test
- `/docker-test python -c "import arcticdb"` — run arbitrary command

## Instructions

Container name: `arc-dev`
Image name: `arcticdb-env`
Dockerfile: `docker/Dockerfile`
Copy link
Copy Markdown
Collaborator

@IvoDD IvoDD Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually subtly different from the docker images we use on the CI. For C++ test I think we use Dockerfile_clang and for python wheel we use the bespoke build_manylinux_image.sh.

It might be useful to add some description of this and information of how the ghcr images are called so when you tell claude "Reproduce this failure on the CI within the docker image" it can figure out which image it needs to pull


### 1. Ensure the image is built

Check if the image exists:
```bash
docker image inspect arcticdb-env >/dev/null 2>&1
```

If it doesn't exist, build it from the repo root:
```bash
docker build -f docker/Dockerfile -t arcticdb-env .
Copy link
Copy Markdown
Contributor

@claude claude Bot Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dockerfile path has diverged from the actual repo structure

The skill says:

Dockerfile: docker/Dockerfile

But the actual file in the repo is docker/Dockerfile (confirmed), so this is correct. However, the build command in Step 1 is:

docker build -f docker/Dockerfile -t arcticdb-env .

Building from the repo root (.) with docker/Dockerfile as context will include the entire repository tree in the Docker build context, which is very large (C++ sources, build artefacts, etc.) and will be slow. Consider adding a note that a .dockerignore file should exist or that users may see a large context upload, or point the build context to the docker/ subdirectory if the Dockerfile permits it.

```

### 2. Ensure the container is running

Check if the container is running:
```bash
docker ps --filter name=arc-dev --format '{{.Names}}' | grep -q arc-dev
Copy link
Copy Markdown
Contributor

@claude claude Bot Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Container check is fragile when a stopped container exists

The "is running" check is:

docker ps --filter name=arc-dev --format '{{.Names}}' | grep -q arc-dev

docker ps only shows running containers. If arc-dev exists but is stopped, this check returns false, and the next step tries docker run, which will fail with Error: Conflict. The container name "/arc-dev" is already in use. The instructions do handle this case, but the flow described is:

  1. Check running → false
  2. Try docker run → fails with a conflict error
  3. Only then is docker start arc-dev mentioned

The agent will likely hit the error before reaching step 3. A more robust ordering would be to check docker ps -a (all containers, including stopped) first, then branch on whether the container exists at all vs. just stopped.

```

If not running, start it with the repo mounted:
```bash
docker run -d --name arc-dev -v "$(pwd)":/workspace -w /workspace arcticdb-env sleep infinity
```
Copy link
Copy Markdown
Contributor

@claude claude Bot Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$(pwd) in a skill file may not produce the expected working directory

docker run -d --name arc-dev -v "$(pwd)":/workspace -w /workspace arcticdb-env sleep infinity

When an AI agent executes this snippet inside a bash -c call (which is the typical skill invocation model), $(pwd) will expand to whatever the agent's current working directory is at that moment — which may or may not be the repository root. If the agent's shell CWD is somewhere else, the wrong directory gets mounted.

Consider documenting that this command must be run from the repository root, or replacing $(pwd) with an explicit path derived from git rev-parse --show-toplevel:

REPO_ROOT=$(git rev-parse --show-toplevel)
docker run -d --name arc-dev -v "$REPO_ROOT":/workspace -w /workspace arcticdb-env sleep infinity


If the container exists but is stopped, start it:
```bash
docker start arc-dev
```

### 3. Execute the command

Run the user's command inside the container:
```bash
docker exec -w /workspace arc-dev $ARGUMENTS
Copy link
Copy Markdown
Contributor

@claude claude Bot Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unquoted $ARGUMENTS may behave unexpectedly

docker exec -w /workspace arc-dev $ARGUMENTS

$ARGUMENTS is unquoted. If the argument string contains spaces (e.g. a file path like python/tests/my test.py) word-splitting will break it across multiple tokens. It also means shell metacharacters in user-provided arguments (semicolons, pipes, backticks) would be interpreted by the shell before Docker sees them.

Since the intended usage is to pass an arbitrary command string (e.g. pytest python/tests/unit/some_test.py), the cleaner form is:

Suggested change
docker exec -w /workspace arc-dev $ARGUMENTS
docker exec -w /workspace arc-dev bash -c "$ARGUMENTS"

This makes it explicit that the full argument string is a shell command fragment, avoids unexpected word-splitting, and matches the interactive usage shown in the Usage section.

```

If no command was provided, ask the user what they want to run.

### 4. Show results

Display the command output. If the command fails, help debug as usual.
Loading