Shields: Problem with Docker build badge: repo not found
=> works fine
=> not found
Same repo. Am I missing something?
sinedied
All 28 comments
Looks like something wrong in the build history API for the project,
sinedied/nano-gateway pulls response:
{
"user": "sinedied",
"name": "nano-gateway",
"namespace": "sinedied",
"repository_type": "image",
"status": 1,
"description": " Lightweight API gateway for home-scale projects",
"is_private": false,
"is_automated": false,
"can_edit": false,
"star_count": 1,
"pull_count": 15,
"last_updated": "2017-12-27T21:46:54.850913Z",
"has_starred": false,
"full_description": "# nano-gateway\n\n[](https://www.npmjs.com/package/nano-gateway) [](https://travis-ci.org/sinedied/nano-gateway)  [](https://microbadger.com/images/sinedied/nano-gateway) [](https://github.com/sindresorhus/xo) [](LICENSE)\n\n\n\n> Lightweight API gateway for home-scale projects.\n\n**Features:**\n- Single-file YAML configuration\n- HTTPS support\n- Secure endpoints with API key\n- URL rewriting\n- Less than [50 LOC](index.js) :smile:\n\n## Installation\n\n```bash\nnpm install -g nano-gateway\n```\n\n## Usage\n```sh\nnanog --help\nUsage: nanog [--config file.yml] [--keygen]\n```\n\nUse the `nanog` command to start the gateway.\n\nBy default, it will use the `config.yml` configuration in the current working directory, but any file can be specified\nusing either the `NANO_GATEWAY_CONFIG` environment variable or the `--config` option.\n\nThe `--keygen` will generate a suitable API key to use in your configuration.\n\n## Configuration\n\nHere is an [example config.yml](config.yml) configuration:\n\n```yaml\nhttp: # optional, enable HTTP gateway\n port: 8080 # optional, specify port for HTTP (default is 8080)\nhttps: # optional, enable HTTPS gateway\n cert: 'cert.pem' # required, certificate path\n key: 'privkey.pem' # required, private key path\n ca: 'chain.pem' # optional, override trusted CA certificates\n port: 8443 # optional, specify port for HTTPS (default is 8443)\nauth: true # optional, enable API key authorization by default for all services\napiKey: '123456' # required if auth is enabled, use nanog --keygen to generate a new key\nservices: # required, define here the services to proxify\n ip: # required, service name\n path: '/ip' # required, endpoint(s) (use Express route syntax, see npmjs.com/path-to-regexp)\n url: 'https://httpbin.org' # required, target url for\n auth: false # optional, authorization can be set or overriden by service\n quote: # another service, add as many as you need\n path: '/jokes/*' # matches any routes under /jokes/\n rewrite: '/jokes/random' # optional, rewrite URL (for syntax, see npmjs.com/express-urlrewrite)\n url: 'https://api.chucknorris.io'\n```\n\n### API key\n\nEndpoints secured by API key can be consumed either by using an `apiKey` query parameter:\n```sh\ncurl https://gateway.com/endpoint?apiKey=<your_api_key>\n```\nor by using an `Authorization` header:\n```sh\ncurl -H \"Authorization: <your_api_key>\" https://gateway.com/endpoint\n```\n\n> Note: It is **strongly** recommended to use only HTTPS with API keys, otherwise your credentials will circulate in\n> clear over the network and may be intercepted.\n\n### HTTPS\n\nTo enable HTTPS you need a valid SSL certificate.\n\nFree [LetsEncrypt](https://letsencrypt.org) certificates can be obtained using [certbot](https://certbot.eff.org).\n\nFor testing purposes, you can also generate a self-signed certificate using this command:\n```sh\nopenssl req -nodes -new -x509 -keyout privkey.pem -out cert.pem\n```\n\nAfter you have your certificate, use it in your configuration like this:\n```yaml\nhttps:\n cert: 'cert.pem'\n key: 'privkey.pem'\n ca: 'chain.pem' # optional, override trusted CA certificates\n```\n\n## Running on Docker\n\nA minimal [Docker image](https://hub.docker.com/r/sinedied/nano-gateway/) based on `node:alpine` is also available\nfor deployment.\n\nYou just need to map a folder with a `config.yml` file in it to the `/config` volume:\n```\ndocker pull sinedied/nano-gateway\ndocker run --d -v <your_config_dir>:/config -p 8443:8443 --name nano-gateway sinedied/nano-gateway\n```\n",
"affiliation": null,
"permissions": {
"read": true,
"write": false,
"admin": false
}
}
sinedied/nano-gateway buildhistory response: (also returns 404 status code)
{
"detail": "Object not found"
}
correct buildhistory reponse:
{
"count": 1572,
"next": "https://registry.hub.docker.com/v2/repositories/jrottenberg/ffmpeg/buildhistory/?page=2",
"previous": null,
"results": [
{
"id": 17779528,
"status": 10,
"created_date": "2017-12-15T15:12:42.511729Z",
"last_updated": "2017-12-16T13:48:55.875532Z",
"build_code": "bdf9g5ua3cd2q8rkmud6hne",
"dockertag_name": "3.1-centos",
"cause": "REPOSITORY_LINK"
},
{
"id": 17771912,
"status": 10,
"created_date": "2017-12-15T13:56:12.675237Z",
"last_updated": "2017-12-16T12:28:34.842744Z",
"build_code": "bmveanfungnkwxk48jcqw6m",
"dockertag_name": "3.2",
"cause": "REPOSITORY_LINK"
},
{
"id": 17771832,
"status": 10,
"created_date": "2017-12-15T13:56:10.751691Z",
"last_updated": "2017-12-16T11:28:48.707129Z",
"build_code": "b5teh6hpgj6yk6tufrqtqdb",
"dockertag_name": "3.4",
"cause": "REPOSITORY_LINK"
},
{
"id": 17771584,
"status": 10,
"created_date": "2017-12-15T13:56:05.890924Z",
"last_updated": "2017-12-16T10:23:44.550701Z",
"build_code": "brsaswwsow2tgsmift2gayw",
"dockertag_name": "3.0-alpine",
"cause": "REPOSITORY_LINK"
},
{
"id": 17771443,
"status": 10,
"created_date": "2017-12-15T13:56:02.887293Z",
"last_updated": "2017-12-16T09:14:47.049854Z",
"build_code": "bzsaayibuc5ejhyingppqxb",
"dockertag_name": "3.1-scratch",
"cause": "REPOSITORY_LINK"
},
{
"id": 17771336,
"status": 10,
"created_date": "2017-12-15T13:56:00.598746Z",
"last_updated": "2017-12-16T08:04:57.543595Z",
"build_code": "bmcop3u4uyrprwo8ztwrnfn",
"dockertag_name": "3.4-scratch",
"cause": "REPOSITORY_LINK"
},
{
"id": 17750450,
"status": -1,
"created_date": "2017-12-15T05:48:00.147004Z",
"last_updated": "2017-12-16T06:50:50.305672Z",
"build_code": "bjexbv4n9zgwukwwpr7bszf",
"dockertag_name": "2.8-scratch",
"cause": "REPOSITORY_LINK"
},
{
"id": 17750447,
"status": -1,
"created_date": "2017-12-15T05:48:00.116812Z",
"last_updated": "2017-12-16T06:43:12.610414Z",
"build_code": "bvllv3357xckhpolynax3nm",
"dockertag_name": "2.8-scratch",
"cause": "REPOSITORY_LINK"
},
{
"id": 17750392,
"status": 10,
"created_date": "2017-12-15T05:47:59.262740Z",
"last_updated": "2017-12-16T05:23:53.647735Z",
"build_code": "bntg2dmyevtzni4lzm9me8e",
"dockertag_name": "2.8-scratch",
"cause": "REPOSITORY_LINK"
},
{
"id": 17743030,
"status": -1,
"created_date": "2017-12-15T03:48:43.823348Z",
"last_updated": "2017-12-16T04:14:53.741367Z",
"build_code": "btcc6mxzkscjl3esthgdm4c",
"dockertag_name": "3.3-scratch",
"cause": "REPOSITORY_LINK"
}
]
}
RedSparr0w
on 28 Dec 2017
I just created the repo on docker hub, maybe it needs some time to chew the info then?
sinedied
on 28 Dec 2017
:crossed_fingers:
Hopefully that is the problem,
Also likes like you have build mode set to manual. (not sure if that makes a difference)
"is_automated": false,
Edit: looks like the docker API may have crashed recently:
RedSparr0w
on 28 Dec 2017
Also likes like you have build mode set to manual. (not sure if that makes a difference)
That's another error, I have setup automated builds 馃槃
sinedied
on 28 Dec 2017
@sinedied can you confirm problem is solved? https://registry.hub.docker.com/v2/repositories/sinedied/nano-gateway/
iamstarkov
on 11 Jan 2018
@iamstarkov it seems to be the build history endpoint that is missing info.
https://registry.hub.docker.com/v2/repositories/sinedied/nano-gateway/buildhistory/
RedSparr0w
on 12 Jan 2018
Yes, it's still not fixed, but it seems the issue is with the docker APIs.
Unless I am missing something on the docker cloud configuration, automated builds + builds history are not recognized through their APIs although it's there:
sinedied
on 12 Jan 2018
I'm seeing the same thing. Out of curiosity - is this resolved on dockers side or do we think this is going to be broken permanently?
gaieges
on 10 May 2018
Not really sure how to go about solving this, i think someone will have to contact docker about it as the API just returns a 404 response with {"detail": "Object not found"} as the body.
Also can't see anything in the docs _(not even sure if i found the correct docs tbh)_
RedSparr0w
on 11 May 2018
I'm having the same issue, would love to hear from anyone who managed to resolve this.
nirizr
on 31 Jul 2018
Just ran into the same thing with one of my projects.
I think this is probably because Docker Hub != Docker Cloud, i.e. builds on Docker Cloud do not show up under the build history in Docker Hub - seems they are treated as two separate build services (see https://stackoverflow.com/a/42736552). From some quick tests, builds generated from Docker Hub show as expected whereas builds from Docker Cloud don't.
I guess a fix would be to also point to the api specific for Docker Cloud builds...
fedjabosnic
on 17 Sep 2018
I am having similar issues with my repository: https://cloud.docker.com/u/genenotebook/repository/docker/genenotebook/genenotebook
Docker pulls are being displayed correctly:
However, automated build is listed incorrectly as manual:
Build status says the repository is not found:
This is incorrect, as I have enabled automated builds and they have completed building.
holmrenser
on 30 Nov 2018
This page is a 404 for me:
https://cloud.docker.com/u/genenotebook/repository/docker/genenotebook/genenotebook
paulmelnikow
on 30 Nov 2018
Interesting, apparently Docker Cloud does not allow browsing.
The repo is also visible through Docker Hub (https://hub.docker.com/r/genenotebook/genenotebook/), but I am using Docker Cloud to build.
holmrenser
on 30 Nov 2018
Ran into the same issue. Noticed that it started happening roughly around the same time as DockerHub UX was revamped. Could it be that DockerHub made some breaking changes to their API?
syedhassaanahmed
on 17 Dec 2018
Yes also got this issue
toitzi
on 2 Jan 2019
Same for me https://github.com/texano00/docker-ionic-android
texano00
on 9 Jan 2019
need to support docker cloud, docker hub may not be used in the future?
fatindeed
on 15 Feb 2019
Just wanted to put out there that Shields is a community project, and that means you can help make this happen! We have a great tutorial and welcome anyone who would like to dig into this! Our maintainer team is happy to provide guidance on the API design and provide assistance with the implementation. We've had many first-time contributors who don't use JavaScript and have tried to make the first-time contributing experience as straightforward as possible.
paulmelnikow
on 18 Feb 2019
An "old" automated build:
$ curl -s 'https://hub.docker.com/api/build/v1/source/?image=xenolf%2Flego' -H 'Accept: application/json' | jq
{
"meta": {
"limit": 25,
"next": null,
"offset": 0,
"previous": null,
"total_count": 0
},
"objects": []
}
A "new" automated build:
$ curl -s 'https://hub.docker.com/api/build/v1/source/?image=ldez%2Fgha-mjolnir' -H 'Accept: application/json' --compressed | jq
{
"meta": {
"limit": 25,
"next": null,
"offset": 0,
"previous": null,
"total_count": 1
},
"objects": [
{
"autotests": "OFF",
"build_in_farm": true,
"build_settings": [
"/api/build/v1/setting/e3db21aa-8847-4789-9f2e-dc136ea432ae/",
"/api/build/v1/setting/6fe17d9d-a946-47f0-a7ae-b20dba0bfb72/"
],
"channel": "Stable",
"image": "ldez/gha-mjolnir",
"owner": "ldez",
"provider": "Github",
"repo_links": false,
"repository": "gha-mjolnir",
"resource_uri": "/api/build/v1/source/9a37d4ca-aad6-4820-932c-5d8bd94fc8d7/",
"state": "Success",
"uuid": "9a37d4ca-aad6-4820-932c-5d8bd94fc8d7"
}
]
}
build_settings: contains the build triggers (each entry is a different trigger). Can be see as the old "automated" flag.
state: for now I know that the value can be Empty, Success. I have to find the other states.
Note: It's possible to use https://cloud.docker.com instead of https://hub.docker.com for the API calls
FYI those API endpoints are called by the hub it-self.
ldez
on 24 Feb 2019
Thanks again @ldez!
3139 adds new badges (Docker Cloud Automated Build and Docker Cloud Build Status) that should provide a working badge for those experiencing issues with the current Docker Automated/Build Status badges. It should get deployed fairly soon, and anyone interested can follow the deployment status of #3139 here
Note that the Docker Cloud badges have a different path with cloud (/docker/cloud/build/:user/:repo vs /docker/build/:user/:repo)
So the path in the OP example: https://img.shields.io/docker/build/sinedied/nano-gateway.svg
Will use the Docker Cloud badge path: https://img.shields.io/docker/cloud/build/sinedied/nano-gateway.svg (this will start working once #3139 is deployed)
calebcartwright
on 5 Mar 2019
It would be helpful to add some documentation to the Docker Build badge guiding people to the new badge for Docker Cloud. What should it say, exactly?
paulmelnikow
on 11 Mar 2019
I was thinking the same thing.
Perhaps something along the lines of:
These badges are for Docker Hub. If you are using Docker Cloud and/or experience issues with these badges, please use the Docker Cloud badges instead (not sure how to best link to those though)
All images created with the new Docker Hub only works with the Docker Cloud badges.
No one really uses the term Docker Cloud: it's just the Docker hub.
https://hub.docker.com/
https://blog.docker.com/2018/12/the-new-docker-hub/
ldez
on 11 Mar 2019
Did not realize Cloud branding had been dropped, thanks for sharing.
This now has me wondering if we really need to have both sets of our Docker badges. Will our new badges (which are currently labeled as Docker Cloud badges) work for all users/images? If so is there any value in keeping our old badges?
calebcartwright
on 11 Mar 2019
Docker badges work well with repositories created before the "new" Docker Hub.
Docker Cloud badges have a flaky behavior or don't work with repositories created with the "old" Docker Hub.
So it's difficult to remove the Docker badges due to that.
ldez
on 11 Mar 2019
I think something along those lines might be best in the docs then, and we could do it on both the "old" Docker Hub badges and the new Docker "Cloud" badges.
I.e. Use this badge if your repository was created after xyz and vice versa
calebcartwright
on 11 Mar 2019
Sounds like a good idea.
Since people don't know they are using Docker "Cloud", maybe it would be good to add /docker/legacy to the old badges and leave a redirect in their place. That might supplement the documentation in helping people choose the right one.
paulmelnikow
on 12 Mar 2019
Related issues
najeeb-ur-rehman
路
3Comments
chadwhitacre
路
4Comments
kerolloz
路
3Comments
Fazendaaa
路
3Comments
kirankotari
路
3Comments
Most helpful comment
I am having similar issues with my repository: https://cloud.docker.com/u/genenotebook/repository/docker/genenotebook/genenotebook
Docker pulls are being displayed correctly:
However, automated build is listed incorrectly as manual:
Build status says the repository is not found:
This is incorrect, as I have enabled automated builds and they have completed building.