gitea/routers/api/packages
merlleu 796ff26e0e
Do not force creation of _cargo-index repo on publish (#27266)
Hello there,
Cargo Index over HTTP is now prefered over git for package updates: we
should not force users who do not need the GIT repo to have the repo
created/updated on each publish (it can still be created in the packages
settings).

The current behavior when publishing is to check if the repo exist and
create it on the fly if not, then update it's content.
Cargo HTTP Index does not rely on the repo itself so this will be
useless for everyone not using the git protocol for cargo registry.

This PR only disable the creation on the fly of the repo when publishing
a crate.

This is linked to #26844 (error 500 when trying to publish a crate if
user is missing write access to the repo) because it's now optional.

---------

Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
2023-10-24 03:26:38 +00:00
..
alpine Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
cargo Do not force creation of _cargo-index repo on publish (#27266) 2023-10-24 03:26:38 +00:00
chef Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
composer Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
conan Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
conda Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
container Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
cran Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
debian Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
generic Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
goproxy Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
helm Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
helper Replace `interface{}` with `any` (#25686) 2023-07-04 18:36:08 +00:00
maven Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
npm Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
nuget Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
pub Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
pypi Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
rpm Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
rubygems Fix the wrong HTTP response status code for duplicate packages (#27480) 2023-10-10 15:39:58 +02:00
swift Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
vagrant Another round of `db.DefaultContext` refactor (#27103) 2023-09-25 13:17:37 +00:00
README.md Add package registry architecture overview (#23445) 2023-03-13 18:15:09 -04:00
api.go Remove redundant "RouteMethods" method (#26024) 2023-07-21 00:43:49 +02:00

README.md

Gitea Package Registry

This document gives a brief overview how the package registry is organized in code.

Structure

The package registry code is divided into multiple modules to split the functionality and make code reuse possible.

Module Description
models/packages Common methods and models used by all registry types
models/packages/<type> Methods used by specific registry type. There should be no need to use type specific models.
modules/packages Common methods and types used by multiple registry types
modules/packages/<type> Registry type specific methods and types (e.g. metadata extraction of package files)
routers/api/packages Route definitions for all registry types
routers/api/packages/<type> Route implementation for a specific registry type
services/packages Helper methods used by registry types to handle common tasks like package creation and deletion in routers
services/packages/<type> Registry type specific methods used by routers and services

Models

Every package registry implementation uses the same underlaying models:

Model Description
Package The root of a package providing values fixed for every version (e.g. the package name)
PackageVersion A version of a package containing metadata (e.g. the package description)
PackageFile A file of a package describing its content (e.g. file name)
PackageBlob The content of a file (may be shared by multiple files)
PackageProperty Additional properties attached to Package, PackageVersion or PackageFile (e.g. used if metadata is needed for routing)

The following diagram shows the relationship between the models:

Package <1---*> PackageVersion <1---*> PackageFile <*---1> PackageBlob

Adding a new package registry type

Before adding a new package registry type have a look at the existing implementation to get an impression of how it could work. Most registry types offer endpoints to retrieve the metadata, upload and download package files. The upload endpoint is often the heavy part because it must validate the uploaded blob, extract metadata and create the models. The methods to validate and extract the metadata should be added in the modules/packages/<type> package. If the upload is valid the methods in services/packages allow to store the upload and create the corresponding models. It depends if the registry type allows multiple files per package version which method should be called:

  • CreatePackageAndAddFile: error if package version already exists
  • CreatePackageOrAddFileToExisting: error if file already exists
  • AddFileToExistingPackage: error if package version does not exist or file already exists

services/packages also contains helper methods to download a file or to remove a package version. There are no helper methods for metadata endpoints because they are very type specific.