Docker integration: breaking change

Ospackage now provides its own Docker image-building API and runs Docker operations in a separate JVM. This prevents its Docker client dependencies from interfering with other plugins or buildscript libraries, including Testcontainers.

This change is intended for a major release.

What changed

• Replaced the bundled bmuschko integration with ospackage-owned task and extension types.
• Introduced ospackageDocker {} for connection and registry settings.
• Removed automatic application of com.bmuschko.docker-remote-api and its transitive dependency.
• Kept the existing plugin IDs and task names: createDockerfile, buildImage, and buildDocker.
• Added process-isolated image building with configuration-cache support.

Migrating Docker builds

Move ospackage's connection and credential settings from docker {} to ospackageDocker {}:

plugins {
    id 'com.netflix.nebula.ospackage-docker'
}

repositories {
    // Supplies the isolated Docker worker's dependencies.
    mavenCentral()
}

ospackageDocker {
    url = providers.environmentVariable('DOCKER_HOST')

    registryCredentials {
        url = 'registry.example.com'
        username = providers.environmentVariable('REGISTRY_USER')
        password = providers.environmentVariable('REGISTRY_PASSWORD')
    }
}

buildImage {
    images.add('example/application:latest')
}

The plugin does not add repositories automatically. Configure a repository that supplies the worker dependencies.

Update imports and typed task configuration.

Before:

import com.bmuschko.gradle.docker.tasks.image.DockerBuildImage

After:

import com.netflix.gradle.plugins.docker.DockerBuildImage

The extension and registry credential types now live under com.netflix.gradle.plugins.docker as well.

Apply com.netflix.nebula.ospackage-docker explicitly to create the image-building tasks. Applying bmuschko alongside the ospackage Docker base plugin no longer activates them.

Compatibility with bmuschko

Builds that still need bmuschko must declare its dependency explicitly, using a version compatible with their existing build.

Both integrations can coexist in the same project:

• ospackageDocker {} configures ospackage's image tasks.
• docker {} continues to configure bmuschko.
• Connection settings and credentials remain independent.
• Task names must remain unique within the project.

Ospackage no longer supplies bmuschko's direct dockerClient access, typed callbacks (onNext, onError, onComplete), or additional Docker task types. Retain bmuschko explicitly if those APIs are required.

Build behavior

• Image builds execute whenever requested; Gradle caching and up-to-date skipping are disabled because images and tags live in an external Docker daemon. Docker's layer cache remains available.
• Configuration-cache reuse is supported.
• Copied and filtered build-context files are staged under a task-owned .ospackage/ directory. Do not exclude this directory through .dockerignore.
• Dockerfile generation and ordinary packaging tasks do not resolve the Docker worker dependencies.
• The production integration does not require the Docker CLI.

No RPM/DEB DSL migration is required. Dependency locks may need regeneration because the published dependency graph has changed.

See PR #506 for implementation details.

Full Changelog: v13.0.2...v14.0.0