CI: de-DINDify

Open
#53,670 3 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Rayan-and-beyond is already working on this.

Since Sep 18, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, github-actions

Research direction

Start with .github/workflows/vm.yml and the ./integration/container, ./integration/build, and ./integration/system targets named in the issue. Compare the current DIND-based execution with the openSUSE test script for reference. Done means these integration areas run in vm.yml without relying on Docker-in-Docker while covering hosts with their standard configuration.

Written by the indexing model from the issue text.

Description

area/testing exp/expert

The current DIND-based CI practically limits the host distribution to Debian userspace + irregular system configuration (systemd, udevd, resolved, etc.) + irregular kernel (Ubuntu, or Oracle on Lima workflows).
https://github.com/moby/moby/blob/8210b0babaed17fbe706a4c5e8c7d0b9c6aba2a1/Dockerfile#L4
https://github.com/moby/moby/blob/8210b0babaed17fbe706a4c5e8c7d0b9c6aba2a1/.github/workflows/test.yml#L35
https://github.com/moby/moby/blob/8210b0babaed17fbe706a4c5e8c7d0b9c6aba2a1/.github/workflows/vm.yml#L46-L47

To cover "real" host OSes with their standard configuration, we have to consider de-DINDifying the CI.
I suggest beginning with de-DINDIfying ./integration/container ./integration/build ./integration/system executed in vm.yml.


openSUSE's test script might be useful for reference https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/tests/containers/docker_engine.pm


  • .vm.yml #53672
  • .test.yml
    • integration
    • integration-cli
    • integration-flaky
    • docker-py
Dominant language
Go
Stars
72.2k
Forks
19.3k
Avg merge
1d 18h
Merged PRs (30d)
157

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from moby/moby

All issues in moby/moby

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.