migrate to github.com/distribution/reference v0.5.0
The "reference" package was moved to a separate module, which was extracted
from b9b19409cf
Also update compose-go, which also switched to distribution/reference;
full diff: https://github.com/compose-spec/compose-go/compare/v1.18.3...v1.18.4
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
pull/2027/head
Sebastiaan van Stijn
1 year ago
parent
978f0fa5c7
commit
2fe7406ef9
@ -0,0 +1 @@
|
|||||||
|
*.go text eol=lf
|
||||||
@ -0,0 +1,2 @@
|
|||||||
|
# Cover profiles
|
||||||
|
*.out
|
||||||
@ -0,0 +1,18 @@
|
|||||||
|
linters:
|
||||||
|
enable:
|
||||||
|
- bodyclose
|
||||||
|
- dupword # Checks for duplicate words in the source code
|
||||||
|
- gofmt
|
||||||
|
- goimports
|
||||||
|
- ineffassign
|
||||||
|
- misspell
|
||||||
|
- revive
|
||||||
|
- staticcheck
|
||||||
|
- unconvert
|
||||||
|
- unused
|
||||||
|
- vet
|
||||||
|
disable:
|
||||||
|
- errcheck
|
||||||
|
|
||||||
|
run:
|
||||||
|
deadline: 2m
|
||||||
@ -0,0 +1,5 @@
|
|||||||
|
# Code of Conduct
|
||||||
|
|
||||||
|
We follow the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).
|
||||||
|
|
||||||
|
Please contact the [CNCF Code of Conduct Committee](mailto:conduct@cncf.io) in order to report violations of the Code of Conduct.
|
||||||
@ -0,0 +1,114 @@
|
|||||||
|
# Contributing to the reference library
|
||||||
|
|
||||||
|
## Community help
|
||||||
|
|
||||||
|
If you need help, please ask in the [#distribution](https://cloud-native.slack.com/archives/C01GVR8SY4R) channel on CNCF community slack.
|
||||||
|
[Click here for an invite to the CNCF community slack](https://slack.cncf.io/)
|
||||||
|
|
||||||
|
## Reporting security issues
|
||||||
|
|
||||||
|
The maintainers take security seriously. If you discover a security
|
||||||
|
issue, please bring it to their attention right away!
|
||||||
|
|
||||||
|
Please **DO NOT** file a public issue, instead send your report privately to
|
||||||
|
[cncf-distribution-security@lists.cncf.io](mailto:cncf-distribution-security@lists.cncf.io).
|
||||||
|
|
||||||
|
## Reporting an issue properly
|
||||||
|
|
||||||
|
By following these simple rules you will get better and faster feedback on your issue.
|
||||||
|
|
||||||
|
- search the bugtracker for an already reported issue
|
||||||
|
|
||||||
|
### If you found an issue that describes your problem:
|
||||||
|
|
||||||
|
- please read other user comments first, and confirm this is the same issue: a given error condition might be indicative of different problems - you may also find a workaround in the comments
|
||||||
|
- please refrain from adding "same thing here" or "+1" comments
|
||||||
|
- you don't need to comment on an issue to get notified of updates: just hit the "subscribe" button
|
||||||
|
- comment if you have some new, technical and relevant information to add to the case
|
||||||
|
- __DO NOT__ comment on closed issues or merged PRs. If you think you have a related problem, open up a new issue and reference the PR or issue.
|
||||||
|
|
||||||
|
### If you have not found an existing issue that describes your problem:
|
||||||
|
|
||||||
|
1. create a new issue, with a succinct title that describes your issue:
|
||||||
|
- bad title: "It doesn't work with my docker"
|
||||||
|
- good title: "Private registry push fail: 400 error with E_INVALID_DIGEST"
|
||||||
|
2. copy the output of (or similar for other container tools):
|
||||||
|
- `docker version`
|
||||||
|
- `docker info`
|
||||||
|
- `docker exec <registry-container> registry --version`
|
||||||
|
3. copy the command line you used to launch your Registry
|
||||||
|
4. restart your docker daemon in debug mode (add `-D` to the daemon launch arguments)
|
||||||
|
5. reproduce your problem and get your docker daemon logs showing the error
|
||||||
|
6. if relevant, copy your registry logs that show the error
|
||||||
|
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
|
||||||
|
|
||||||
|
## 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:
|
||||||
|
|
||||||
|
1. Use your own [fork](https://help.github.com/en/articles/about-forks)
|
||||||
|
2. Create your [change](https://github.com/containerd/project/blob/master/CONTRIBUTING.md#successful-changes)
|
||||||
|
3. Test your code
|
||||||
|
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)
|
||||||
|
|
||||||
|
Refer to [containerd's contribution guide](https://github.com/containerd/project/blob/master/CONTRIBUTING.md#successful-changes)
|
||||||
|
for tips on creating a successful contribution.
|
||||||
|
|
||||||
|
## Sign your work
|
||||||
|
|
||||||
|
The sign-off is a simple line at the end of the explanation for the patch. Your
|
||||||
|
signature certifies that you wrote the patch or otherwise have the right to pass
|
||||||
|
it on as an open-source patch. The rules are pretty simple: if you can certify
|
||||||
|
the below (from [developercertificate.org](http://developercertificate.org/)):
|
||||||
|
|
||||||
|
```
|
||||||
|
Developer Certificate of Origin
|
||||||
|
Version 1.1
|
||||||
|
|
||||||
|
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
|
||||||
|
660 York Street, Suite 102,
|
||||||
|
San Francisco, CA 94110 USA
|
||||||
|
|
||||||
|
Everyone is permitted to copy and distribute verbatim copies of this
|
||||||
|
license document, but changing it is not allowed.
|
||||||
|
|
||||||
|
Developer's Certificate of Origin 1.1
|
||||||
|
|
||||||
|
By making a contribution to this project, I certify that:
|
||||||
|
|
||||||
|
(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
|
||||||
|
indicated in the file; or
|
||||||
|
|
||||||
|
(b) The contribution is based upon previous work that, to the best
|
||||||
|
of my knowledge, is covered under an appropriate open source
|
||||||
|
license and I have the right under that license to submit that
|
||||||
|
work with modifications, whether created in whole or in part
|
||||||
|
by me, under the same open source license (unless I am
|
||||||
|
permitted to submit under a different license), as indicated
|
||||||
|
in the file; or
|
||||||
|
|
||||||
|
(c) The contribution was provided directly to me by some other
|
||||||
|
person who certified (a), (b) or (c) and I have not modified
|
||||||
|
it.
|
||||||
|
|
||||||
|
(d) I understand and agree that this project and the contribution
|
||||||
|
are public and that a record of the contribution (including all
|
||||||
|
personal information I submit with it, including my sign-off) is
|
||||||
|
maintained indefinitely and may be redistributed consistent with
|
||||||
|
this project or the open source license(s) involved.
|
||||||
|
```
|
||||||
|
|
||||||
|
Then you just add a line to every git commit message:
|
||||||
|
|
||||||
|
Signed-off-by: Joe Smith <joe.smith@email.com>
|
||||||
|
|
||||||
|
Use your real name (sorry, no pseudonyms or anonymous contributions.)
|
||||||
|
|
||||||
|
If you set your `user.name` and `user.email` git configs, you can sign your
|
||||||
|
commit automatically with `git commit -s`.
|
||||||
@ -0,0 +1,144 @@
|
|||||||
|
# distribution/reference Project Governance
|
||||||
|
|
||||||
|
Distribution [Code of Conduct](./CODE-OF-CONDUCT.md) can be found here.
|
||||||
|
|
||||||
|
For specific guidance on practical contribution steps please
|
||||||
|
see our [CONTRIBUTING.md](./CONTRIBUTING.md) guide.
|
||||||
|
|
||||||
|
## Maintainership
|
||||||
|
|
||||||
|
There are different types of maintainers, with different responsibilities, but
|
||||||
|
all maintainers have 3 things in common:
|
||||||
|
|
||||||
|
1) They share responsibility in the project's success.
|
||||||
|
2) They have made a long-term, recurring time investment to improve the project.
|
||||||
|
3) They spend that time doing whatever needs to be done, not necessarily what
|
||||||
|
is the most interesting or fun.
|
||||||
|
|
||||||
|
Maintainers are often under-appreciated, because their work is harder to appreciate.
|
||||||
|
It's easy to appreciate a really cool and technically advanced feature. It's harder
|
||||||
|
to appreciate the absence of bugs, the slow but steady improvement in stability,
|
||||||
|
or the reliability of a release process. But those things distinguish a good
|
||||||
|
project from a great one.
|
||||||
|
|
||||||
|
## Reviewers
|
||||||
|
|
||||||
|
A reviewer is a core role within the project.
|
||||||
|
They share in reviewing issues and pull requests and their LGTM counts towards the
|
||||||
|
required LGTM count to merge a code change into the project.
|
||||||
|
|
||||||
|
Reviewers are part of the organization but do not have write access.
|
||||||
|
Becoming a reviewer is a core aspect in the journey to becoming a maintainer.
|
||||||
|
|
||||||
|
## Adding maintainers
|
||||||
|
|
||||||
|
Maintainers are first and foremost contributors that have shown they are
|
||||||
|
committed to the long term success of a project. Contributors wanting to become
|
||||||
|
maintainers are expected to be deeply involved in contributing code, pull
|
||||||
|
request review, and triage of issues in the project for more than three months.
|
||||||
|
|
||||||
|
Just contributing does not make you a maintainer, it is about building trust
|
||||||
|
with the current maintainers of the project and being a person that they can
|
||||||
|
depend on and trust to make decisions in the best interest of the project.
|
||||||
|
|
||||||
|
Periodically, the existing maintainers curate a list of contributors that have
|
||||||
|
shown regular activity on the project over the prior months. From this list,
|
||||||
|
maintainer candidates are selected and proposed in a pull request or a
|
||||||
|
maintainers communication channel.
|
||||||
|
|
||||||
|
After a candidate has been announced to the maintainers, the existing
|
||||||
|
maintainers are given five business days to discuss the candidate, raise
|
||||||
|
objections and cast their vote. Votes may take place on the communication
|
||||||
|
channel or via pull request comment. Candidates must be approved by at least 66%
|
||||||
|
of the current maintainers by adding their vote on the mailing list. The
|
||||||
|
reviewer role has the same process but only requires 33% of current maintainers.
|
||||||
|
Only maintainers of the repository that the candidate is proposed for are
|
||||||
|
allowed to vote.
|
||||||
|
|
||||||
|
If a candidate is approved, a maintainer will contact the candidate to invite
|
||||||
|
the candidate to open a pull request that adds the contributor to the
|
||||||
|
MAINTAINERS file. The voting process may take place inside a pull request if a
|
||||||
|
maintainer has already discussed the candidacy with the candidate and a
|
||||||
|
maintainer is willing to be a sponsor by opening the pull request. The candidate
|
||||||
|
becomes a maintainer once the pull request is merged.
|
||||||
|
|
||||||
|
## Stepping down policy
|
||||||
|
|
||||||
|
Life priorities, interests, and passions can change. If you're a maintainer but
|
||||||
|
feel you must remove yourself from the list, inform other maintainers that you
|
||||||
|
intend to step down, and if possible, help find someone to pick up your work.
|
||||||
|
At the very least, ensure your work can be continued where you left off.
|
||||||
|
|
||||||
|
After you've informed other maintainers, create a pull request to remove
|
||||||
|
yourself from the MAINTAINERS file.
|
||||||
|
|
||||||
|
## Removal of inactive maintainers
|
||||||
|
|
||||||
|
Similar to the procedure for adding new maintainers, existing maintainers can
|
||||||
|
be removed from the list if they do not show significant activity on the
|
||||||
|
project. Periodically, the maintainers review the list of maintainers and their
|
||||||
|
activity over the last three months.
|
||||||
|
|
||||||
|
If a maintainer has shown insufficient activity over this period, a neutral
|
||||||
|
person will contact the maintainer to ask if they want to continue being
|
||||||
|
a maintainer. If the maintainer decides to step down as a maintainer, they
|
||||||
|
open a pull request to be removed from the MAINTAINERS file.
|
||||||
|
|
||||||
|
If the maintainer wants to remain a maintainer, but is unable to perform the
|
||||||
|
required duties they can be removed with a vote of at least 66% of the current
|
||||||
|
maintainers. In this case, maintainers should first propose the change to
|
||||||
|
maintainers via the maintainers communication channel, then open a pull request
|
||||||
|
for voting. The voting period is five business days. The voting pull request
|
||||||
|
should not come as a surpise to any maintainer and any discussion related to
|
||||||
|
performance must not be discussed on the pull request.
|
||||||
|
|
||||||
|
## How are decisions made?
|
||||||
|
|
||||||
|
Docker distribution is an open-source project with an open design philosophy.
|
||||||
|
This means that the repository is the source of truth for EVERY aspect of the
|
||||||
|
project, including its philosophy, design, road map, and APIs. *If it's part of
|
||||||
|
the project, it's in the repo. If it's in the repo, it's part of the project.*
|
||||||
|
|
||||||
|
As a result, all decisions can be expressed as changes to the repository. An
|
||||||
|
implementation change is a change to the source code. An API change is a change
|
||||||
|
to the API specification. A philosophy change is a change to the philosophy
|
||||||
|
manifesto, and so on.
|
||||||
|
|
||||||
|
All decisions affecting distribution, big and small, follow the same 3 steps:
|
||||||
|
|
||||||
|
* Step 1: Open a pull request. Anyone can do this.
|
||||||
|
|
||||||
|
* Step 2: Discuss the pull request. Anyone can do this.
|
||||||
|
|
||||||
|
* Step 3: Merge or refuse the pull request. Who does this depends on the nature
|
||||||
|
of the pull request and which areas of the project it affects.
|
||||||
|
|
||||||
|
## Helping contributors with the DCO
|
||||||
|
|
||||||
|
The [DCO or `Sign your work`](./CONTRIBUTING.md#sign-your-work)
|
||||||
|
requirement is not intended as a roadblock or speed bump.
|
||||||
|
|
||||||
|
Some 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.
|
||||||
|
|
||||||
|
## I'm a maintainer. Should I make pull requests too?
|
||||||
|
|
||||||
|
Yes. Nobody should ever push to master directly. All changes should be
|
||||||
|
made through a pull request.
|
||||||
|
|
||||||
|
## Conflict Resolution
|
||||||
|
|
||||||
|
If you have a technical dispute that you feel has reached an impasse with a
|
||||||
|
subset of the community, any contributor may open an issue, specifically
|
||||||
|
calling for a resolution vote of the current core maintainers to resolve the
|
||||||
|
dispute. The same voting quorums required (2/3) for adding and removing
|
||||||
|
maintainers will apply to conflict resolution.
|
||||||
@ -0,0 +1,26 @@
|
|||||||
|
# Distribution project maintainers & reviewers
|
||||||
|
#
|
||||||
|
# See GOVERNANCE.md for maintainer versus reviewer roles
|
||||||
|
#
|
||||||
|
# MAINTAINERS (cncf-distribution-maintainers@lists.cncf.io)
|
||||||
|
# GitHub ID, Name, Email address
|
||||||
|
"chrispat","Chris Patterson","chrispat@github.com"
|
||||||
|
"clarkbw","Bryan Clark","clarkbw@github.com"
|
||||||
|
"corhere","Cory Snider","csnider@mirantis.com"
|
||||||
|
"deleteriousEffect","Hayley Swimelar","hswimelar@gitlab.com"
|
||||||
|
"heww","He Weiwei","hweiwei@vmware.com"
|
||||||
|
"joaodrp","João Pereira","jpereira@gitlab.com"
|
||||||
|
"justincormack","Justin Cormack","justin.cormack@docker.com"
|
||||||
|
"squizzi","Kyle Squizzato","ksquizzato@mirantis.com"
|
||||||
|
"milosgajdos","Milos Gajdos","milosthegajdos@gmail.com"
|
||||||
|
"sargun","Sargun Dhillon","sargun@sargun.me"
|
||||||
|
"wy65701436","Wang Yan","wangyan@vmware.com"
|
||||||
|
"stevelasker","Steve Lasker","steve.lasker@microsoft.com"
|
||||||
|
#
|
||||||
|
# REVIEWERS
|
||||||
|
# GitHub ID, Name, Email address
|
||||||
|
"dmcgowan","Derek McGowan","derek@mcgstyle.net"
|
||||||
|
"stevvooe","Stephen Day","stevvooe@gmail.com"
|
||||||
|
"thajeztah","Sebastiaan van Stijn","github@gone.nl"
|
||||||
|
"DavidSpek", "David van der Spek", "vanderspek.david@gmail.com"
|
||||||
|
"Jamstah", "James Hewitt", "james.hewitt@gmail.com"
|
||||||
@ -0,0 +1,25 @@
|
|||||||
|
# Project packages.
|
||||||
|
PACKAGES=$(shell go list ./...)
|
||||||
|
|
||||||
|
# Flags passed to `go test`
|
||||||
|
BUILDFLAGS ?=
|
||||||
|
TESTFLAGS ?=
|
||||||
|
|
||||||
|
.PHONY: all build test coverage
|
||||||
|
.DEFAULT: all
|
||||||
|
|
||||||
|
all: build
|
||||||
|
|
||||||
|
build: ## no binaries to build, so just check compilation suceeds
|
||||||
|
go build ${BUILDFLAGS} ./...
|
||||||
|
|
||||||
|
test: ## run tests
|
||||||
|
go test ${TESTFLAGS} ./...
|
||||||
|
|
||||||
|
coverage: ## generate coverprofiles from the unit tests
|
||||||
|
rm -f coverage.txt
|
||||||
|
go test ${TESTFLAGS} -cover -coverprofile=cover.out ./...
|
||||||
|
|
||||||
|
.PHONY: help
|
||||||
|
help:
|
||||||
|
@awk 'BEGIN {FS = ":.*##"; printf "\nUsage:\n make \033[36m\033[0m\n"} /^[a-zA-Z_\/%-]+:.*?##/ { printf " \033[36m%-27s\033[0m %s\n", $$1, $$2 } /^##@/ { printf "\n\033[1m%s\033[0m\n", substr($$0, 5) } ' $(MAKEFILE_LIST)
|
||||||
@ -0,0 +1,30 @@
|
|||||||
|
# Distribution reference
|
||||||
|
|
||||||
|
Go library to handle references to container images.
|
||||||
|
|
||||||
|
<img src="/distribution-logo.svg" width="200px" />
|
||||||
|
|
||||||
|
[](https://github.com/distribution/reference/actions?query=workflow%3ACI)
|
||||||
|
[](https://pkg.go.dev/github.com/distribution/reference)
|
||||||
|
[](LICENSE)
|
||||||
|
[](https://codecov.io/gh/distribution/reference)
|
||||||
|
[](https://app.fossa.com/projects/custom%2B162%2Fgithub.com%2Fdistribution%2Freference?ref=badge_shield)
|
||||||
|
|
||||||
|
This repository contains a library for handling refrences to container images held in container registries. Please see [godoc](https://pkg.go.dev/github.com/distribution/reference) for details.
|
||||||
|
|
||||||
|
## Contribution
|
||||||
|
|
||||||
|
Please see [CONTRIBUTING.md](CONTRIBUTING.md) for details on how to contribute
|
||||||
|
issues, fixes, and patches to this project.
|
||||||
|
|
||||||
|
## 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](https://slack.cncf.io/)
|
||||||
|
that everyone is welcome to join and chat about development.
|
||||||
|
|
||||||
|
## Licenses
|
||||||
|
|
||||||
|
The distribution codebase is released under the [Apache 2.0 license](LICENSE).
|
||||||
@ -0,0 +1,7 @@
|
|||||||
|
# Security Policy
|
||||||
|
|
||||||
|
## Reporting a Vulnerability
|
||||||
|
|
||||||
|
The maintainers take security seriously. If you discover a security issue, please bring it to their attention right away!
|
||||||
|
|
||||||
|
Please DO NOT file a public issue, instead send your report privately to cncf-distribution-security@lists.cncf.io.
|
||||||
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 8.6 KiB |
Loading…
Reference in New Issue