I'm getting errors when trying to build from the 3.8 tag with either alpine:3.8 or gliderlabs/alpine:3.8 even though docker hub is listing 3.8 as latest.
> docker pull alpine:3.8
Error response from daemon: manifest for alpine:3.8 not found
> docker pull gliderlabs/alpine:3.8
Error response from daemon: manifest for gliderlabs/alpine:3.8 not found
If you look on https://hub.docker.com/r/library/alpine/tags/ the tags that are available are over a month old where the repo info is saying it is available at https://hub.docker.com/r/library/alpine/
It would be great if the tags could be updated.
Same issue. But the offical images repo has been updated. https://github.com/docker-library/official-images/blob/master/library/alpine https://github.com/docker-library/official-images/commit/d754738b6f42bd95c794511d9210f5c1a3ad4da8
https://doi-janky.infosiftr.net/job/multiarch/job/amd64/job/alpine/44/
I think the build is stuck.
@ncopa @yosifkit Any ideas what is going on?
Manifest is there but when it comes to linux/amd64:
3.8: Pulling from library/alpine
no matching manifest for linux/amd64 in the manifest list entries
Same here
Using default tag: latest
latest: Pulling from library/alpine
no matching manifest for linux/amd64 in the manifest list entries
Manifest. Manifest. Where are you?
Using default tag: latest
latest: Pulling from library/alpine
no matching manifest for linux/amd64 in the manifest list entries
All of the builds that relied on the latest version of the alpine image now fail, is there a way to address that problem?
@MrLokans Never use lastest version...? Just pin it to 3.7, and update the pin as soon as 3.8 is out.
[edit] since people apparently voted down my answer here... let met explain:
still seeing this for latest and 3.8:
docker pull alpine:latest
latest: Pulling from library/alpine
no matching manifest for linux/amd64 in the manifest list entries
@frenck this issue was opened because the 3.8 image was broken not because the latest tag was being abused.
I welcome the latest and greatest and don't want to be updating in excess of 1000 docker files when a new version of the alpine image is released. I also want my builds to start screaming when something new comes along and breaks them.
@jakekeeys I know.
I was replying to @MrLokans, who asked for a way to address his currently failing builds, so my answer was perfectly valid for his issue and was in no way a solution for the missing manifest.
You choose not to pin, that is fine (as long that is a conscious choice). I currently actively maintain 250+ containers and pin everything. It is the only way to guarantee the resulting images works as tested and intended. Yes, it adds extra maintenance.
About the issue at hand, I hope it gets addressed soon 馃憤
Build 45 for amd64 has been triggered and succeeded:
https://doi-janky.infosiftr.net/job/multiarch/job/amd64/job/alpine/45/console
Was experiencing this but looks like the build finishing resolved it.
We had a temporary issue with our main amd64 build host that I've now corrected (as you've noticed). Build was successful, manifest lists should be pushed soon (or already). :+1:
@frenck, sorry, I was not clear enough, that was not in my own dockerfile, I worked with the dockerized teamcity, that relied upon the java image, which in turn relied upon the alpine base image.
For some reason docker-compose was not working well with resolving this image inheritance graph and broke down (even though the Java image seems to have the alpine version pinned)
Most helpful comment
We had a temporary issue with our main amd64 build host that I've now corrected (as you've noticed). Build was successful, manifest lists should be pushed soon (or already). :+1: