## Motivation and Context
- Adds credentials for the new MCP Registry Login GitHub Apps (local,
staging, prod)
- Adds support for "none" auth to publisher
## How Has This Been Tested?
- Tested publisher workflows locally
- Unit and integration tests passing
## Breaking Changes
None
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
---
Merging based on Tadas's approval review, and only making minor docs changes on top of that.
Fixes#264. Adds endpoints:
```
/v0/auth/github # exchange a github token for a registry token that gives you access to namespaces io.github.username and io.github.org for your orgs
/v0/auth/none # get a registry token for namespace io.modelcontextprotocol.anonymous (only for testing/local dev purposes)
```
Updates `/v0/publish` to accept one of these registry tokens.
## Motivation and Context
See #264
## How Has This Been Tested?
- Running locally and getting a token from `/v0/auth/none` and then
publishing to `/v0/publish`
- Updating the integration tests that get a token and then publish, and
them passing
## Breaking Changes
This is a breaking change to the auth API. This is fine for registry
given it's not deployed yet.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: adam jones <domdomegg@users.noreply.github.com>
Issue: links directive was failing on podman
- Removed unsupported 'links' directive for Podman compatibility
<!-- Provide a brief summary of your changes -->
It was failing on Podman because Podman doesn't support the links
directive that Docker Compose does, and we already using depends_on,
which establishes the dependency relationship between services; we can
simply remove the links section from your docker-compose.yml file.
## Motivation and Context
docker-compose -links deprecated #107
Fix the defect by removing link.
## How Has This Been Tested?
Yes. Test by running on both.
For Docker run.
docker build -t registry .
docker compose up
For Podman
podman build -t registry .
podman compose up
## Breaking Changes
Yes for podman.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ x] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ x] My code follows the repository's style guidelines
- [ x] New and existing tests pass locally
- [ x] I have added appropriate error handling
- [x ] I have added or updated documentation as needed
## Additional context
It is related to issue #107
Co-authored-by: Avinash Sridhar <sridharavinash@users.noreply.github.com>
Co-authored-by: adam jones <domdomegg+git@gmail.com>
Auto build image when we run `docker compose up`, Make it start more
easy for beginner.
## Motivation and Context
When I try to use `docker compose up` start the MCP server, docker
default pull `registry` image from dockerhub, because I forget build
image first.
Maybe we don't need to manually build the image, just build it
automatically when docker compose starts
## How Has This Been Tested?
Just run `docker-compose up --build` at a environment has installed
docker and docker compose.
Signed-off-by: 疯魔慕薇 <kfanjian@gmail.com>
Co-authored-by: adam jones <domdomegg+git@gmail.com>
