You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The plugin currently has some functionality that can be used to remove images, containers and volumes that are created during project builds, but lacks a general build environment cleanup task that can reset the Docker server to a known state prior to build. In contrast, a typical build that produces output on the filesystem is easily reset with the clean goal from maven-clean-plugin.
Info
When building a project, the initial state of the Docker server can impact the build unpredictably.
Existing images with a given tag may be used as the base for a build, vs pulling fresh from the source.
Old versions of images from previous executions of the build may not be cleaned up in a subsequent run if names or tags are altered, e.g. due to the use of timestamps or SCM revision information in tags.
Images and volumes associated with containers that stopped, but were not removed, or with containers that kept running when a build failed before stopping them, cannot be easily removed without first stopping and removing the container(s).
Working around these issues with the existing goals is limited due to the focus in the existing goals on keeping actions related to previous actions in the build. For example, docker:stop will default to stopping containers that are noted to have been started in the same Maven session. Additionally, containers started by the docker:start goal are labelled with dmp.coordinates=groupId:artifactId:version, which breaks down in the case where artifacts from old versions should be cleaned.
Rather than adding wildcard behaviours to existing goals, as proposed in PR #900, I think a better option is to introduce a new goal, docker:clean, that is more aggressive about resetting the server than existing goals.
I'm reconsidering this proposal after looking into the code more closely 😅
The first issue is that the configuration example above would put the clean goal in conflict with all the other goals, since they already define <volumes> and <images> as something other than a list of strings. The clean goal could deviate from this standard, but it would not easily coexist with plugin global configuration.
Further, the functionality above could be mostly achieved with the existing stop and possibly volume-remove goals, but the stop should be executed first (ideally with removeVolumes=true, allContainers=true, and containerNamePattern=something-without-index-placeholder). Adding an image name pattern option as in PR #900 would make the existing docker:stop more powerful.
Description
The plugin currently has some functionality that can be used to remove images, containers and volumes that are created during project builds, but lacks a general build environment cleanup task that can reset the Docker server to a known state prior to build. In contrast, a typical build that produces output on the filesystem is easily reset with the clean goal from maven-clean-plugin.
Info
When building a project, the initial state of the Docker server can impact the build unpredictably.
Working around these issues with the existing goals is limited due to the focus in the existing goals on keeping actions related to previous actions in the build. For example, docker:stop will default to stopping containers that are noted to have been started in the same Maven session. Additionally, containers started by the docker:start goal are labelled with
dmp.coordinates=groupId:artifactId:version
, which breaks down in the case where artifacts from old versions should be cleaned.Rather than adding wildcard behaviours to existing goals, as proposed in PR #900, I think a better option is to introduce a new goal, docker:clean, that is more aggressive about resetting the server than existing goals.
Example POM
mvn -v
) : 3.5.0+The text was updated successfully, but these errors were encountered: