Add integration tests using Testcontainers

[ilopezluna]

This pull request introduces integration testing support for the CLI, enabling end-to-end validation of model registry and runner interactions using Docker containers.

model-cli (what its being tested) <----> DMR (Testcontainer) <----> OCI Registry (Testcontainer)
The registry is set as the default one in here.

We can easily add more tests, for other commands like tag, configure, etc, but it can be done in a followup PR.
I added a separated workflow because it needs to build the DMR image (the current latest does not include the env variable to customize default registry yet), once we publish a new latest we can move the workflow to the normal CI.

The PR also contains a fix for the inspect command.

@mdelapenya could you please take a look? Let us know any recommendation you might have 🙏

[doringeman]

LGTM! Why isn't the integration-tests rule in the root Makefile?

[ilopezluna]

I'm adding this additional workflow because I have to build the DMR image before running tests. This temporary, integration test should be run in the normal CI workflow

[ilopezluna]

Note: modelID and digest are exactly the same (the digest of the manifest) I just added 2 fields to make it more readable

[ilopezluna]

LGTM! Why isn't the integration-tests rule in the root Makefile?

I keep it in a separated workflow for now because we need to build DMR image with current version of DMR, otherwise we cannot define the default registry

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• integration_test.go is very large—consider breaking it into smaller files or extracting common setup/teardown logic into helper functions to improve readability and maintainability.
• The go.mod diff includes a lot of indirect module updates; please run go mod tidy to remove unused dependencies and keep the module file clean.
• Instead of calling testcontainers.CleanupContainer/Network directly, register cleanup with t.Cleanup so resources are always cleaned up even if setup fails early.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- integration_test.go is very large—consider breaking it into smaller files or extracting common setup/teardown logic into helper functions to improve readability and maintainability.
- The go.mod diff includes a lot of indirect module updates; please run `go mod tidy` to remove unused dependencies and keep the module file clean.
- Instead of calling testcontainers.CleanupContainer/Network directly, register cleanup with t.Cleanup so resources are always cleaned up even if setup fails early.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[doringeman]

Why only PullModel?

To fix the problem, explicitly define a permissions block with the least privilege needed. Since this workflow job (integration-test) only checks out code and runs tests but does not perform any write operations, the minimal permission needed is contents: read. The best approach is to add:

permissions:
  contents: read

This block can be added at the workflow root (applies to all jobs), or more specifically, to the integration-test job (since there’s only one job here, either location is functionally the same). Place the block above or within the relevant job definition.

To implement this, add permissions: contents: read just below runs-on: ubuntu-latest and above timeout-minutes: 10 (line 9 in the snippet). No other changes or dependency modifications are necessary.

---

[mdelapenya]

suggestion: I'd avoid using the build tag unless necessary. Why? Because then you'll be running tests twice (adding the flag in the make file will run all AND will include files with this tag), so you can end up adding exclusions and complex boolean logic for this. My recommendation is to run them altogether, and treat in-process integration tests as unit tests, as they are blazing fast thanks to containers.

[ilopezluna]

That's a good point, thank you!

[ericcurtin]

Minor nit, logs report error when we have a valid fallback:

cmd/cli/model-cli inspect smollm2:latest
INFO[0001] Getting model by reference: smollm2:latest    component=model-manager
ERRO[0001] Failed to get model: model not found reference: smollm2:latest  component=model-manager
INFO[0001] Getting model by reference: ai/smollm2:latest  component=model-manager
{
    "id": "sha256:354bf30d0aa3af413d2aa5ae4f23c66d78980072d1e07a5b0d776e9606a2f0b9",
    "tags": [
        "index.docker.io/ai/smollm2:latest",
        "my-smollm2:latest"
    ],
    "created": 1742816981,
    "config": {
        "format": "gguf",
        "quantization": "IQ2_XXS/Q4_K_M",
        "parameters": "361.82 M",
        "architecture": "llama",
        "size": "256.35 MiB"
    }
}
+ MODEL_RUNNER_HOST=http://localhost:13434
+ cmd/cli/model-cli inspect my-smollm2