Consider this Jenkins pipeline step that builds a Docker image and tags it:
stage('Build Docker Image') {
steps {
script {
dockerImage = docker.build("myapp:${env.BUILD_NUMBER}")
echo dockerImage.id
}
}
}What will be printed by echo dockerImage.id?
stage('Build Docker Image') { steps { script { dockerImage = docker.build("myapp:${env.BUILD_NUMBER}") echo dockerImage.id } } }
Think about what docker.build() returns and what id represents.
The docker.build() method returns a Docker image object. The id property is the unique hash ID of the built image, which Jenkins can print.
You have built a Docker image in Jenkins with tag myapp:${env.BUILD_NUMBER}. Which step correctly pushes this image to Docker Hub?
Remember Jenkins needs to authenticate to Docker Hub before pushing.
docker.withRegistry() wraps the push command with authentication. Calling dockerImage.push() inside it pushes the tagged image correctly.
Given this snippet:
stage('Push Image') {
steps {
script {
dockerImage = docker.build("myapp:${env.BUILD_NUMBER}")
dockerImage.push()
}
}
}The pipeline fails with an authentication error. What is the most likely cause?
Think about how Jenkins authenticates to Docker registries.
Without docker.withRegistry and credentials, Jenkins cannot authenticate to Docker Hub, causing push to fail.
Why do DevOps teams prefer storing Docker images as build artifacts in Jenkins pipelines?
Think about consistency and reliability in deployments.
Storing Docker images as artifacts ensures the same tested image is deployed, avoiding differences between build and production.
Choose the Jenkins pipeline snippet that correctly builds a Docker image, tags it with the build number and 'latest', pushes both tags to Docker Hub, and uses credentials securely.
Look for correct tag usage, push order, and secure credential handling.
Option C builds with the build number tag, pushes that tag and 'latest' inside a docker.withRegistry block using credentials. This is the recommended secure and clear approach.