Open xtremerui opened 1 year ago
Further observation is this could also affect a resource type or image resoure that with type
to be registry-image-resource. When the check again returns a version without digest, for any step that runs on the image, it will errored by
image fetching failed
when the step is trying to initilize the container by first pulling the base image for it.
im experiening the same problem since yesterday the pipeline has not been updated in a while so it seems a change within docker.io
- name: metalink-repository
source:
repository: dpb587/metalink-repository-resource
type: registry-image
the following error i get at the get step
fetching dpb587/metalink-repository-resource@
ERRO[0000] download failed: get image: GET https://index.docker.io/v2/dpb587/metalink-repository-resource/manifests/: unexpected status code 404 Not Found: 404 page not found
the suggested workaround to move to docker-image works
We noticed the same issue in our environment and this only happened if no tag is present as some of our resources still worked
Doesn't work and shows the same issue
resource_types:
- name: google-cloud-storage
type: registry-image
source:
repository: frodenas/gcs-resource
However the following resource type does work and is able to pull the latest tag. This means that the tag is not optional anymore when used with registry-image.
resource_types:
- name: google-cloud-storage
type: registry-image
source:
repository: frodenas/gcs-resource
tag: latest
thx for the update. there is potential some logic diff for querying docker with or without tag. I will look into it.
Here's a sql query to find any resource config versions with a blank digest. We found ~10 of them in our instance:
select * from resource_config_versions where version @> '{"digest": ""}'
Based on @jpalermo 's comment, if your custom resource type or image resource that based on registry-image-resource encounter this problem, you can do
delete from resource_config_versions where version @> '{"digest": ""}'
to clear those invalid versions. After this build should be running as usual.
We're experiencing similar error in our pipeline since around 19th-22nd Nov and I can confirm that @FelixMarxIBM solution works. Error we were getting was
ERRO[0000] download failed: get image: GET https://index.docker.io/v2/aoldershaw/git-branches-resource/manifests/: unexpected status code 404 Not Found: 404 page not found
I also opened an issue on dockerhub side. https://github.com/docker/hub-feedback/issues/2292
This behaviour has being only found in some resources with type
registry-image-resource
accross production CI. Could be a glitch of docker API whencheck
querying for version info. When there is newer version other than this problematic one available, thecheck
will work again most likely.And when this happens, the get step of this resource will fail by error
since no digest was provided for the GET request.
The temp workaround is to disable that bad version and rerun the build OR switching to docker-image resource.