f9c1b86feb
This replace rule is to prevent unwanted updates of grpc and jwt-go. When updating spf13/cobra, we noticed that google.golang.org/grpc got updated. Doing a search to find which modules (note here that `go mod graph` only looks at dependencies from a `go modules` perspective, and not all the (current version) of our dependencies use go modules). And I found that the only _modules_ depending on it are `github.com/spf13/viper` and `github.com/grpc-ecosystem/grpc-gateway`: ```bash $ go mod graph | grep ' google.golang.org/grpc' github.com/spf13/viper@v1.4.0 google.golang.org/grpc@v1.21.0 github.com/grpc-ecosystem/grpc-gateway@v1.9.0 google.golang.org/grpc@v1.19.0 ``` Of those, `github.com/grpc-ecosystem/grpc-gateway` is a dependency of `github.com/spf13/viper`: ```bash $ go mod graph | grep ' github.com/grpc-ecosystem/grpc-gateway' github.com/spf13/viper@v1.4.0 github.com/grpc-ecosystem/grpc-gateway@v1.9.0 ``` So looking at that one, it's a dependency of cobra: ```bash $ go mod graph | grep ' github.com/spf13/viper@v1.4.0' github.com/spf13/cobra@v1.0.0 github.com/spf13/viper@v1.4.0 ``` Ironically, while both `github.com/spf13/viper` and `github.com/grpc-ecosystem/grpc-gateway`, depend on `google.golang.org/grpc` and (through their `go.mod`) are responsible for `go mod` to update the dependency version of grpc, none of them are used: ```bash cat vendor/modules.txt | grep github.com/spf13/viper cat vendor/modules.txt | grep github.com/grpc-ecosystem/grpc-gateway ``` Unfortunately, `go modules` looks at `go.mod` to determine the *minimum version* required; _even if the parts of the modules specifying it in the `go.mod` are unused_. This patch adds a `replace` rule in go.mod to prevent updating grpc based on other dependencies that _declare_ `google.golang.org/grpc` as a dependency, but are not used and, hence, should not influence the minumum version. Signed-off-by: Sebastiaan van Stijn <github@gone.nl> |
||
|---|---|---|
| .github | ||
| cmd | ||
| configuration | ||
| context | ||
| contrib | ||
| digestset | ||
| docs | ||
| health | ||
| manifest | ||
| metrics | ||
| notifications | ||
| project | ||
| reference | ||
| registry | ||
| releases | ||
| script | ||
| tests | ||
| testutil | ||
| uuid | ||
| vendor | ||
| version | ||
| .gitignore | ||
| .golangci.yml | ||
| .mailmap | ||
| ADOPTERS.md | ||
| blobs.go | ||
| BUILDING.md | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| distribution-logo.svg | ||
| doc.go | ||
| docker-bake.hcl | ||
| Dockerfile | ||
| errors.go | ||
| go.mod | ||
| go.sum | ||
| GOVERNANCE.md | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| manifests.go | ||
| README.md | ||
| registry.go | ||
| ROADMAP.md | ||
| tags.go | ||
Distribution
The toolset to pack, ship, store, and deliver content.
This repository's main product is the Open Source Registry implementation for storing and distributing container images using the OCI Distribution Specification. The goal of this project is to provide a simple, secure, and scalable base for building a large scale registry solution or running a simple private registry. It is a core library for many registry operators including Docker Hub, GitHub Container Registry, GitLab Container Registry and DigitalOcean Container Registry, as well as the CNCF Harbor Project, and VMware Harbor Registry.
This repository contains the following components:
| Component | Description |
|---|---|
| registry | An implementation of the OCI Distribution Specification. |
| libraries | A rich set of libraries for interacting with distribution components. Please see godoc for details. Note: The interfaces for these libraries are unstable. |
| documentation | Docker's full documentation set is available at docs.docker.com. This repository contains the subset related just to the registry. |
How does this integrate with Docker, containerd, and other OCI client?
Clients implement against the OCI specification and communicate with the registry using HTTP. This project contains a client implementation which is currently in use by Docker, however, it is deprecated for the implementation in containerd and will not support new features.
What are the long term goals of the Distribution project?
The Distribution project has the further long term goal of providing a secure tool chain for distributing content. The specifications, APIs and tools should be as useful with Docker as they are without.
Our goal is to design a professional grade and extensible content distribution system that allow users to:
- Enjoy an efficient, secured and reliable way to store, manage, package and exchange content
- Hack/roll their own on top of healthy open-source components
- Implement their own home made solution through good specs, and solid extensions mechanism.
Contribution
Please see CONTRIBUTING.md for details on how to contribute issues, fixes, and patches to this project. If you are contributing code, see the instructions for building a development environment.
Communication
For async communication and long running discussions please use issues and pull requests on the github repo. This will be the best place to discuss design and implementation.
For sync communication we have a #distribution channel in the CNCF Slack that everyone is welcome to join and chat about development.
Licenses
The distribution codebase is released under the Apache 2.0 license. The README.md file, and files in the "docs" folder are licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at http://creativecommons.org/licenses/by/4.0/.