Closed lalvarezsanc closed 2 years ago
@lalvarezsanc @bhoflich Hi Luis, I apologize for not getting to this yesterday, I had an urgent issue come up.
I tested "docker images -a | grep \"weathervane*\" | awk '{print \$3}' | xargs docker rmi" on the CICD driver VM. Afterward, I found some remaining images that were not named 'weathervane-' but were still used during the build.
Before running the cleanup command (I obfuscated the repo just to be on the safe side..)
After running cleanup command:
You might consider if you want to specify these for deletion.
The CICD pipeline where this was tested specifies to download openjdk and harbor-repo.vmware.com/dockerhub-proxy-cache/library/openjdk images from Corporate Harbor because if not specified, it was defaulting to download from DockerHub which was failing. If the default DockerHub download was succeeding, I'm not sure whether the result of cleanup would be the same or not, that is, you would want to test what the openjdk repository and tag would read.
Regarding the container cleanup command, did you confirm that the container created on the driver during build can be filtered using "weathervane*"? Here's the containers that were present on my Driver prior to cleanup, notice the names are not specified:
@RebeccaYo @bhoflich
Hi Rebecca thanks for taking a look at this.
I fixed the image removal command to also include the images you mentioned and successfully tested it. However, I do not seem to get any leftover containers after the running buildDockerImages script so I am unsure if the container removal command will work as intended (I thought it was because I wasn't seeing any containers left after running the script). While running the script, I noticed that containers are created and then deleted as the script progresses with no containers left after the script finishes running. Maybe the leftover containers are due to running weathervane—I'll double check.
However, I do not seem to get any leftover containers after the running buildDockerImages script
I believe the container is left over when the script is aborted midway. I wouldn't expect it to be left on normal execution.
Calling docker rmi -f $(docker images -q) and docker container prune -f within cleanupAfterBuild subroutine.