zeekayandHanzo Dev
1414fd6ce0
Our own documentation called the product Gitea. It is Hanzo Forge, so it now says so — README family, CONTRIBUTING, docs/, and the per-package READMEs. Three kinds of "Gitea" are not branding, and they stay: - MIT attribution: the copyright header template, the LICENSE, and the "white-label fork of Gitea" statement in each README. - Provenance: modules/git came from go-gitea/git, the Actions token design was proposed upstream in #24635, the base is 1.26.4 of go-gitea/gitea. - Addressing values: /data/gitea and /etc/gitea, the gitea-data PVC, the GITEA__ env prefix, X-Gitea-* headers. LLM.md's inventory of these is unchanged. Links that pointed at upstream infrastructure described a project this fork is not. Contributor issues, security reports and documentation now land here; the Crowdin sync, the GiteaBot backporter, the blog PR and the dl.gitea.com asset checks describe no lane this repo has, and the release section now records the one it does — tag, push to canonical, semver image, universe pin. Four references were dead as written, not merely upstream: - docs/setup.md is docs/build-setup.md - build/backport-locale.go does not exist - .github/workflows does not exist here; the workflows are .hanzo/workflows - the -X ldflags named code.gitea.io/gitea symbols, which this binary has none of, so the linker set nothing. The module path is github.com/hanzoai/git and cmd.PIDFile defaults to /run/gitd.pid. gitea help and gitea completion are gitd. gitea-runner is git-runner. The GitHub repo is hanzoai/forge now, so the clone and fork URLs point there. ghcr.io/hanzoai/git is untouched: a package is not renamed by a repo rename and the running deployment pins that image. The Go module path is untouched for the same reason — go.mod still declares github.com/hanzoai/git. Co-authored-by: Hanzo Dev <[email protected]>
2.9 KiB
Hanzo Forge 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 underlying 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 existsCreatePackageOrAddFileToExisting: error if file already existsAddFileToExistingPackage: 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.