github.com/webwurst/docker@v1.7.0/docs/docker-hub/repos.md (about) 1 <!--[metadata]> 2 +++ 3 title = "Your Repositories on Docker Hub" 4 description = "Your Repositories on Docker Hub" 5 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, webhooks, docs, documentation"] 6 [menu.main] 7 parent = "smn_pubhub" 8 weight = 2 9 +++ 10 <![end-metadata]--> 11 12 # Your Hub repositories 13 14 Docker Hub repositories make it possible for you to share images with co-workers, 15 customers or the Docker community at large. If you're building your images internally, 16 either on your own Docker daemon, or using your own Continuous integration services, 17 you can push them to a Docker Hub repository that you add to your Docker Hub user or 18 organization account. 19 20 Alternatively, if the source code for your Docker image is on GitHub or Bitbucket, 21 you can use an "Automated build" repository, which is built by the Docker Hub 22 services. See the [automated builds documentation](./builds.md) to read about 23 the extra functionality provided by those services. 24 25  26 27 Your Docker Hub repositories have a number of useful features. 28 29 ## Stars 30 31 Your repositories can be starred and you can star repositories in 32 return. Stars are a way to show that you like a repository. They are 33 also an easy way of bookmarking your favorites. 34 35 ## Comments 36 37 You can interact with other members of the Docker community and maintainers by 38 leaving comments on repositories. If you find any comments that are not 39 appropriate, you can flag them for review. 40 41 ## Collaborators and their role 42 43 A collaborator is someone you want to give access to a private 44 repository. Once designated, they can `push` and `pull` to your 45 repositories. They will not be allowed to perform any administrative 46 tasks such as deleting the repository or changing its status from 47 private to public. 48 49 > **Note:** 50 > A collaborator cannot add other collaborators. Only the owner of 51 > the repository has administrative access. 52 53 You can also assign more granular collaborator rights ("Read", "Write", or "Admin") 54 on Docker Hub by using organizations and groups. For more information 55 see the [accounts documentation](accounts/). 56 57 ## Private repositories 58 59 Private repositories allow you to have repositories that contain images 60 that you want to keep private, either to your own account or within an 61 organization or group. 62 63 To work with a private repository on [Docker 64 Hub](https://hub.docker.com), you will need to add one via the [Add 65 Repository](https://registry.hub.docker.com/account/repositories/add/) 66 link. You get one private repository for free with your Docker Hub 67 account. If you need more accounts you can upgrade your [Docker 68 Hub](https://registry.hub.docker.com/plans/) plan. 69 70 Once the private repository is created, you can `push` and `pull` images 71 to and from it using Docker. 72 73 > *Note:* You need to be signed in and have access to work with a 74 > private repository. 75 76 Private repositories are just like public ones. However, it isn't 77 possible to browse them or search their content on the public registry. 78 They do not get cached the same way as a public repository either. 79 80 It is possible to give access to a private repository to those whom you 81 designate (i.e., collaborators) from its Settings page. From there, you 82 can also switch repository status (*public* to *private*, or 83 vice-versa). You will need to have an available private repository slot 84 open before you can do such a switch. If you don't have any available, 85 you can always upgrade your [Docker 86 Hub](https://registry.hub.docker.com/plans/) plan. 87 88 ## Webhooks 89 90 A webhook is an HTTP call-back triggered by a specific event. 91 You can use a Hub repository webhook to notify people, services, and other 92 applications after a new image is pushed to your repository (this also happens 93 for Automated builds). For example, you can trigger an automated test or 94 deployment to happen as soon as the image is available. 95 96 To get started adding webhooks, go to the desired repository in the Hub, 97 and click "Webhooks" under the "Settings" box. 98 A webhook is called only after a successful `push` is 99 made. The webhook calls are HTTP POST requests with a JSON payload 100 similar to the example shown below. 101 102 *Example webhook JSON payload:* 103 104 ``` 105 { 106 "callback_url": "https://registry.hub.docker.com/u/svendowideit/busybox/hook/2141bc0cdec4hebec411i4c1g40242eg110020/", 107 "push_data": { 108 "images": [ 109 "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3", 110 "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c", 111 ... 112 ], 113 "pushed_at": 1.417566822e+09, 114 "pusher": "svendowideit" 115 }, 116 "repository": { 117 "comment_count": 0, 118 "date_created": 1.417566665e+09, 119 "description": "", 120 "full_description": "webhook triggered from a 'docker push'", 121 "is_official": false, 122 "is_private": false, 123 "is_trusted": false, 124 "name": "busybox", 125 "namespace": "svendowideit", 126 "owner": "svendowideit", 127 "repo_name": "svendowideit/busybox", 128 "repo_url": "https://registry.hub.docker.com/u/svendowideit/busybox/", 129 "star_count": 0, 130 "status": "Active" 131 } 132 ``` 133 134 <TODO: does it tell you what tag was updated?> 135 136 For testing, you can try an HTTP request tool like [requestb.in](http://requestb.in/). 137 138 > **Note**: The Docker Hub servers are currently in the IP range 139 > `162.242.195.64 - 162.242.195.127`, so you can restrict your webhooks to 140 > accept webhook requests from that set of IP addresses. 141 142 ### Webhook chains 143 144 Webhook chains allow you to chain calls to multiple services. For example, 145 you can use this to trigger a deployment of your container only after 146 it has been successfully tested, then update a separate Changelog once the 147 deployment is complete. 148 After clicking the "Add webhook" button, simply add as many URLs as necessary 149 in your chain. 150 151 The first webhook in a chain will be called after a successful push. Subsequent 152 URLs will be contacted after the callback has been validated. 153 154 ### Validating a callback 155 156 In order to validate a callback in a webhook chain, you need to 157 158 1. Retrieve the `callback_url` value in the request's JSON payload. 159 1. Send a POST request to this URL containing a valid JSON body. 160 161 > **Note**: A chain request will only be considered complete once the last 162 > callback has been validated. 163 164 To help you debug or simply view the results of your webhook(s), 165 view the "History" of the webhook available on its settings page. 166 167 #### Callback JSON data 168 169 The following parameters are recognized in callback data: 170 171 * `state` (required): Accepted values are `success`, `failure` and `error`. 172 If the state isn't `success`, the webhook chain will be interrupted. 173 * `description`: A string containing miscellaneous information that will be 174 available on the Docker Hub. Maximum 255 characters. 175 * `context`: A string containing the context of the operation. Can be retrieved 176 from the Docker Hub. Maximum 100 characters. 177 * `target_url`: The URL where the results of the operation can be found. Can be 178 retrieved on the Docker Hub. 179 180 *Example callback payload:* 181 182 { 183 "state": "success", 184 "description": "387 tests PASSED", 185 "context": "Continuous integration by Acme CI", 186 "target_url": "http://ci.acme.com/results/afd339c1c3d27" 187 } 188 189 ## Mark as unlisted 190 191 By marking a repository as unlisted, you can create a publicly pullable repository 192 which will not be in the Hub or commandline search. This allows you to have a limited 193 release, but does not restrict access to anyone that is told, or guesses the repository 194 name.