1 Answer
- Newest
- Most votes
- Most comments
1
If you set up a Jenkinsfile like this, don't you log in every time?
https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html
https://www.jenkins.io/doc/book/pipeline/docker/
pipeline{
agent any
stages{
stage('Hoge') {
steps{
script{
docker.withRegistry("https://${AWSAccountID}.dkr.ecr.${ECR Region}.amazonaws.com") {
sh("`aws ecr get-login --no-include-email --region ${ECR Region}`")
docker.image('my-custom-image').inside {
sh("echo 'hoge'")
}
}
}
}
}
}
}
Relevant content
- asked 10 months ago
- asked 13 days ago
- asked a year ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
AFAIK, this one is better than the try / catch: I don't see why the second login in cache block would succeed if initial on just failed. They will be quasi-simultanous. The issue that you described initially is more of a timeout happening long after initial login so that will be ineffective.
The token expiry happens quite randomly. It does not happen always. So if indeed the token has expired, we need to be doing reauthentication as per AWS suggestion. Hence, believed that the try catch will ensure that it will perform the reauthentication in case of failure.
Are you suggesting that changing to docker.withRegistry will solve the issue for us? May I know why the withDockerContainer gives back such issues?
I'm not sure why withDockerContainer would cause the token expiration issue, but I believe docker.withRegistry logs you in every time you run with a build.
Understood. I will give this a try. There is also a recommendation to cleanup current user docker credentials using sh 'rm ~/.docker/config.json || true' on https://docs.cloudbees.com/docs/cloudbees-ci-kb/latest/client-and-managed-controllers/withdockerregistry-step-fails-with-amazon-ecr and https://plugins.jenkins.io/amazon-ecr/. If I include that it is introducing delays in the docker image download and times out. Is the docker credentials cleanup necessary?