[JIRA] (JENKINS-49677) Docker image tag based on hash of Dockerfile
Title: Message Title Gavin Llewellyn commented on JENKINS-49677 Re: Docker image tag based on hash of Dockerfile Looks good to me, thanks for the quick response! Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49677) Docker image tag based on hash of Dockerfile
Title: Message Title
Gavin Llewellyn created an issue
Jenkins / JENKINS-49677
Docker image tag based on hash of Dockerfile
Issue Type:
Bug
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2018-02-21 16:32
Priority:
Major
Reporter:
Gavin Llewellyn
I've got a multi-branch declarative pipeline build job that uses
agent { dockerfile true }
to set up a container for the build. Multiple branches have an identical Dockerfile, but building an image produces different results, as the result also depends on other files in the repository. We recently had a job that failed due to two branches building in parallel; after much head scratching we realised the same tag had been applied to both of the two docker images built, so one of the branches ended up being built inside a container based on the other branch's image. Digging in to the code, I can see that the image tag is currently based on the hash of the Dockerfile - I think this is flawed, as identical Dockerfiles do not necessarily produce the same output. I can think of two other options:
Use a tag based on the (full) job name
Use a randomly generated tag
I believe Docker is already pretty clever about re-using cached intermediate images, so I don't think these changes will have a significant impact on subsequent image build times, even if a random tag is used.
[JIRA] (JENKINS-40723) Built Dockerfile images are never removed
Title: Message Title Gavin Llewellyn commented on JENKINS-40723 Re: Built Dockerfile images are never removed At the moment, the Dockerfile builds are fairly quick after the first build, as Docker's cache is used to avoid rebuilding any Dockerfile steps that haven't changed. This caching would be defeated if the built image was deleted after each build (unless the Docker node has similar images that are not managed by Jenkins). Determining whether an image should be rebuilt is not necessarily as simple as checking whether the Dockerfile has changed, or that a previous image built for that same Dockerfile still exists. I think this logic should be left to Docker, and not replicated in Jenkins. My suggestion would be the following: When building a Dockerfile, tag the resulting image with the job name/Id instead of the Dockerfile hash. Before building a Dockerfile, check for an existing image using the job's tag. If an image exists, note the image ID. After building a Dockerfile, check the image ID of the current image with the job's tag. If the image ID has changed (i.e. the tag has moved), delete the old image. If a job's name is changed, or a job is deleted, there may be some images left orphaned in the Docker node. However, it will be much easier for an admin to clean these up in the future, as the tags would make it obvious what the images were used for. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40723) Built Dockerfile images are never removed
Title: Message Title Gavin Llewellyn created an issue Jenkins / JENKINS-40723 Built Dockerfile images are never removed Issue Type: Bug Assignee: Andrew Bayer Components: pipeline-model-definition-plugin Created: 2016/Dec/29 5:16 PM Environment: Jenkins 2.19.3, pipeline-model-definition-plugin 0.6 Priority: Minor Reporter: Gavin Llewellyn When using a Dockerfile to set up the build environment (as added in JENKINS-39216), a docker image is built and tagged with the SHA1 hash of the Dockerfile. Nothing seems to remove this image once the build competes, so disk space on the docker node will eventually be exhausted. Add Comment
[JIRA] (JENKINS-40226) Dockerfile build failures do not trigger failure post section
Title: Message Title
Gavin Llewellyn created an issue
Jenkins / JENKINS-40226
Dockerfile build failures do not trigger failure post section
Issue Type:
Bug
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2016/Dec/05 5:09 PM
Environment:
Jenkins 2.19.3, pipeline-model-definition-plugin 0.6
Priority:
Minor
Reporter:
Gavin Llewellyn
I am using the new Dockerfile support added in JENKINS-39216. I also have a "post" section within "pipeline" in my Jenkinsfile set up to send notifications of the build result:
pipeline {
// Build environment is defined by the Dockerfile
agent dockerfile:true
stages {
stage('package') {
steps {
// Do build
}
}
}
post {
success {
hipchatSend color: "GREEN", message: "SUCCESS: ${currentBuild.absoluteUrl}\">${currentBuild.fullDisplayName}"
}
failure {
hipchatSend color: "RED", message: "FAILURE: ${currentBuild.absoluteUrl}\">${currentBuild.fullDisplayName}", notify: true
}
unstable {
hipchatSend color: "YELLOW", message: "UNSTABLE: ${currentBuild.absoluteUrl}\">${currentBuild.fullDisplayName}", notify: true
}
}
}
However, if a failure occurs during the Dockerfile image build (e.g. a non-zero return code from a RUN step), the build is marked as failed but no notification is sent.
