@ -16,10 +17,8 @@ Then please do not report your issue here - you should instead report it to [htt
- can't figure out something
- can't figure out something
- are not sure what's going on or what your problem is
- are not sure what's going on or what your problem is
Then please do not open an issue here yet - you should first try one of the following support forums:
Please ask first in the #distribution channel on Docker community slack.
[Click here for an invite to Docker community slack](https://dockr.ly/slack)
- irc: #docker-distribution on freenode
- mailing-list: <distribution@dockerproject.org> or https://groups.google.com/a/dockerproject.org/forum/#!forum/distribution
### Reporting security issues
### Reporting security issues
@ -59,90 +58,72 @@ By following these simple rules you will get better and faster feedback on your
7. provide any relevant detail about your specific Registry configuration (e.g., storage backend used)
7. provide any relevant detail about your specific Registry configuration (e.g., storage backend used)
8. indicate if you are using an enterprise proxy, Nginx, or anything else between you and your Registry
8. indicate if you are using an enterprise proxy, Nginx, or anything else between you and your Registry
## Contributing a patch for a known bug, or a small correction
## Contributing Code
Contributions should be made via pull requests. Pull requests will be reviewed
by one or more maintainers or reviewers and merged when acceptable.
You should follow the basic GitHub workflow:
You should follow the basic GitHub workflow:
1. fork
1. Use your own [fork](https://help.github.com/en/articles/about-forks)
2. commit a change
2. Create your [change](https://github.com/containerd/project/blob/master/CONTRIBUTING.md#successful-changes)
3. make sure the tests pass
3. Test your code
4. PR
4. [Commit](https://github.com/containerd/project/blob/master/CONTRIBUTING.md#commit-messages) your work, always [sign your commits](https://github.com/containerd/project/blob/master/CONTRIBUTING.md#commit-messages)
5. Push your change to your fork and create a [Pull Request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request-from-a-fork)
Additionally, you must [sign your commits](https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work). It's very simple:
Refer to [containerd's contribution guide](https://github.com/containerd/project/blob/master/CONTRIBUTING.md#successful-changes)
- configure your name with git: `git config user.name "Real Name" && git config user.email mail@example.com`
for tips on creating a successful contribution.
- sign your commits using `-s`: `git commit -s -m "My commit"`
## Sign your work
Some simple rules to ensure quick merge:
The sign-off is a simple line at the end of the explanation for the patch. Your
- clearly point to the issue(s) you want to fix in your PR comment (e.g., `closes #12345`)
signature certifies that you wrote the patch or otherwise have the right to pass
- prefer multiple (smaller) PRs addressing individual issues over a big one trying to address multiple issues at once
it on as an open-source patch. The rules are pretty simple: if you can certify
- if you need to amend your PR following comments, please squash instead of adding more commits
the below (from [developercertificate.org](http://developercertificate.org/)):
## Contributing new features
```
Developer Certificate of Origin
You are heavily encouraged to first discuss what you want to do. You can do so on the irc channel, or by opening an issue that clearly describes the use case you want to fulfill, or the problem you are trying to solve.
Version 1.1
If this is a major new feature, you should then submit a proposal that describes your technical solution and reasoning.
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
If you did discuss it first, this will likely be greenlighted very fast. It's advisable to address all feedback on this proposal before starting actual work.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
Then you should submit your implementation, clearly linking to the issue (and possible proposal).
Everyone is permitted to copy and distribute verbatim copies of this
Your PR will be reviewed by the community, then ultimately by the project maintainers, before being merged.
license document, but changing it is not allowed.
It's mandatory to:
Developer's Certificate of Origin 1.1
- interact respectfully with other community members and maintainers - more generally, you are expected to abide by the [Docker community rules](https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines)
By making a contribution to this project, I certify that:
- address maintainers' comments and modify your submission accordingly
- write tests for any new code
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
Complying to these simple rules will greatly accelerate the review process, and will ensure you have a pleasant experience in contributing code to the Registry.
indicated in the file; or
Have a look at a great, successful contribution: the [Swift driver PR](https://github.com/docker/distribution/pull/493)
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
## Coding Style
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
Unless explicitly stated, we follow all coding guidelines from the Go
by me, under the same open source license (unless I am
community. While some of these standards may seem arbitrary, they somehow seem
permitted to submit under a different license), as indicated
to result in a solid, consistent codebase.
in the file; or
It is possible that the code base does not currently comply with these
(c) The contribution was provided directly to me by some other
guidelines. We are not looking for a massive PR that fixes this, since that
person who certified (a), (b) or (c) and I have not modified
goes against the spirit of the guidelines. All new contributions should make a
it.
best effort to clean up and make the code base better than they left it.
Obviously, apply your best judgement. Remember, the goal here is to make the
(d) I understand and agree that this project and the contribution
code base easier for humans to navigate and understand. Always keep that in
are public and that a record of the contribution (including all
mind when nudging others to comply.
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
The rules:
this project or the open source license(s) involved.
```
1. All code should be formatted with `gofmt -s`.
2. All code should pass the default levels of
Then you just add a line to every git commit message:
[`golint`](https://github.com/golang/lint).
3. All code should follow the guidelines covered in [Effective
Signed-off-by: Joe Smith <joe.smith@email.com>
Go](http://golang.org/doc/effective_go.html) and [Go Code Review
requirement is not intended as a roadblock or speed bump.
Some distribution contributors are not as familiar with `git`, or have used a web
based editor, and thus asking them to `git commit --amend -s` is not the best
way forward.
In this case, maintainers can update the commits based on clause (c) of the DCO.
The most trivial way for a contributor to allow the maintainer to do this, is to
add a DCO signature in a pull requests's comment, or a maintainer can simply
note that the change is sufficiently trivial that it does not substantially
change the existing contribution - i.e., a spelling change.
When you add someone's DCO, please also add your own to keep a log.
"""
[Rules."no direct push"]
title = "I'm a maintainer. Should I make pull requests too?"
text = """
Yes. Nobody should ever push to master directly. All changes should be
made through a pull request.
"""
[Rules.tsc]
title = "Conflict Resolution and technical disputes"
text = """
distribution defers to the [Technical Steering Committee](https://github.com/moby/tsc) for escalations and resolution on disputes for technical matters."
"""
[Rules.meta]
title = "How is this process changed?"
text = "Just like everything else: by making a pull request :)"
# Current project organization
[Org]
[Org.Maintainers]
people = [
"dmcgowan",
"dmp42",
"stevvooe",
]
[Org.Reviewers]
people = [
"manishtomar",
"caervs",
"davidswu",
"RobbKistler"
]
[people]
# A reference list of all people associated with the project.
# All other sections should refer to people by their canonical key
| **registry** | An implementation of the [Docker Registry HTTP API V2](docs/spec/api.md) for use with docker 1.6+. |
| **registry** | An implementation of the [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec). |
| **libraries** | A rich set of libraries for interacting with distribution components. Please see [godoc](https://godoc.org/github.com/docker/distribution) for details. **Note**: These libraries are **unstable**. |
| **libraries** | A rich set of libraries for interacting with distribution components. Please see [godoc](https://godoc.org/github.com/docker/distribution) for details. **Note**: The interfaces for these libraries are **unstable**. |
| **specifications** | _Distribution_ related specifications are available in [docs/spec](docs/spec) |
| **documentation** | Docker's full documentation set is available at [docs.docker.com](https://docs.docker.com). This repository [contains the subset](docs/) related just to the registry. |
| **documentation** | Docker's full documentation set is available at [docs.docker.com](https://docs.docker.com). This repository [contains the subset](docs/) related just to the registry. |
### How does this integrate with Docker engine?
### How does this integrate with Docker, containerd, and other OCI client?
This project should provide an implementation to a V2 API for use in the [Docker
Clients implement against the OCI specification and communicate with the
core project](https://github.com/docker/docker). The API should be embeddable
registry using HTTP. This project contains an client implementation which
and simplify the process of securely pulling and pushing content from `docker`
is currently in use by Docker, however, it is deprecated for the
daemons.
[implementation in containerd](https://github.com/containerd/containerd/tree/master/remotes/docker)
and will not support new features.
### What are the long term goals of the Distribution project?
### What are the long term goals of the Distribution project?
@ -43,18 +44,6 @@ system that allow users to:
* Implement their own home made solution through good specs, and solid
* Implement their own home made solution through good specs, and solid
extensions mechanism.
extensions mechanism.
## More about Registry 2.0
The new registry implementation provides the following benefits:
- faster push and pull
- new, more efficient implementation
- simplified deployment
- pluggable storage backend
- webhook notifications
For information on upcoming functionality, please see [ROADMAP.md](ROADMAP.md).
### Who needs to deploy a registry?
### Who needs to deploy a registry?
By default, Docker users pull images from Docker's public registry instance.
By default, Docker users pull images from Docker's public registry instance.
@ -78,53 +67,25 @@ For those who have previously deployed their own registry based on the Registry
data migration is required. A tool to assist with migration efforts has been
data migration is required. A tool to assist with migration efforts has been
created. For more information see [docker/migrator](https://github.com/docker/migrator).
created. For more information see [docker/migrator](https://github.com/docker/migrator).
## Contribute
## Contribution
Please see [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to contribute
Please see [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to contribute
issues, fixes, and patches to this project. If you are contributing code, see
issues, fixes, and patches to this project. If you are contributing code, see
the instructions for [building a development environment](BUILDING.md).
the instructions for [building a development environment](BUILDING.md).
## Support
## Communication
If any issues are encountered while using the _Distribution_ project, several
For async communication and long running discussions please use issues and pull requests on the github repo.
avenues are available for support:
This will be the best place to discuss design and implementation.
<table>
For sync communication we have a community slack with a #distribution channel that everyone is welcome to join and chat about development.
<tr>
<thalign="left">
**Slack:** Catch us in the #distribution channels on dockercommunity.slack.com.
IRC
[Click here for an invite to Docker community slack.](https://dockr.ly/slack)
</th>
<td>
## Licenses
#docker-distribution on FreeNode
</td>
The distribution codebase is released under the [Apache 2.0 license](LICENSE).
</tr>
The README.md file, and files in the "docs" folder are licensed under the
<tr>
Creative Commons Attribution 4.0 International License. You may obtain a
<thalign="left">
copy of the license, titled CC-BY-4.0, at http://creativecommons.org/licenses/by/4.0/.
returnfmt.Errorf("http2: TLSConfig.CipherSuites is missing an HTTP/2-required AES_128_GCM_SHA256 cipher.")
returnfmt.Errorf("http2: TLSConfig.CipherSuites is missing an HTTP/2-required AES_128_GCM_SHA256 cipher (need at least one of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256).")
}
}
}
}
@ -322,7 +322,7 @@ type ServeConnOpts struct {
}
}
func(o*ServeConnOpts)context()context.Context{
func(o*ServeConnOpts)context()context.Context{
ifo.Context!=nil{
ifo!=nil&&o.Context!=nil{
returno.Context
returno.Context
}
}
returncontext.Background()
returncontext.Background()
@ -581,13 +581,10 @@ type stream struct {
cancelCtxfunc()
cancelCtxfunc()
// owned by serverConn's serve loop:
// owned by serverConn's serve loop:
bodyBytesint64// body bytes seen so far
bodyBytesint64// body bytes seen so far
declBodyBytesint64// or -1 if undeclared
declBodyBytesint64// or -1 if undeclared
flowflow// limits writing from Handler to client
flowflow// limits writing from Handler to client
inflowflow// what the client is allowed to POST/etc to us
inflowflow// what the client is allowed to POST/etc to us
parent*stream// or nil
numTrailerValuesint64
weightuint8
statestreamState
statestreamState
resetQueuedbool// RST_STREAM queued for write; set by sc.resetStream
resetQueuedbool// RST_STREAM queued for write; set by sc.resetStream
gotTrailerHeaderbool// HEADER frame for trailers was seen
gotTrailerHeaderbool// HEADER frame for trailers was seen
iwilltry42
4 years ago