Point app registry docs at railiance-forge
This commit is contained in:
@@ -1,77 +1,16 @@
|
||||
# Gitea Container Registry
|
||||
|
||||
## Registry Target
|
||||
|
||||
Use `gitea.coulomb.social` as the approved registry host. The `/v2` ingress is
|
||||
live as of 2026-05-15 and returns the OCI registry authentication challenge over
|
||||
HTTPS.
|
||||
|
||||
Registry-specific Gitea settings are carried in
|
||||
`helm/gitea-registry-values.yaml`, a non-secret overlay applied after the SOPS
|
||||
values file by `make gitea-deploy`. It explicitly enables packages, permits
|
||||
container and PyPI uploads without an app-level size cap, clears globally
|
||||
disabled repo units, and moves `ROOT_URL` to the HTTPS host.
|
||||
|
||||
Image names should use the Gitea owner and package path:
|
||||
|
||||
```bash
|
||||
gitea.coulomb.social/coulomb/state-hub:<tag>
|
||||
```
|
||||
|
||||
The State Hub handoff from `CUST-WP-0011` should publish the locally verified
|
||||
`state-hub:local` image under that name.
|
||||
|
||||
The successful smoke-test tags were:
|
||||
|
||||
```bash
|
||||
gitea.coulomb.social/coulomb/state-hub:6186a99
|
||||
gitea.coulomb.social/coulomb/state-hub:latest
|
||||
```
|
||||
|
||||
Digest:
|
||||
Canonical registry operating guidance now lives in:
|
||||
|
||||
```text
|
||||
sha256:039d29654ccb3754c6ecdbe497c6364bbd8452edcdcb7fa937dd9debf5b734ff
|
||||
/home/worsch/railiance-forge/docs/gitea-container-registry.md
|
||||
```
|
||||
|
||||
## Operator Smoke Test
|
||||
This compatibility pointer remains in `railiance-apps` while deploy-capable
|
||||
Gitea Helm, SOPS, and manifest files are still migrating under
|
||||
`RAILIANCE-WP-0006-T03`.
|
||||
|
||||
Use a Gitea personal access token with package read/write permission:
|
||||
|
||||
```bash
|
||||
docker login gitea.coulomb.social
|
||||
docker tag state-hub:local gitea.coulomb.social/coulomb/state-hub:<tag>
|
||||
docker push gitea.coulomb.social/coulomb/state-hub:<tag>
|
||||
docker pull gitea.coulomb.social/coulomb/state-hub:<tag>
|
||||
```
|
||||
|
||||
The `coulomb` organization packages are public by default, so the verified
|
||||
cluster pull for `state-hub:6186a99` did not require an `imagePullSecret`.
|
||||
|
||||
For private packages, create an image pull secret in each consuming namespace:
|
||||
|
||||
```bash
|
||||
kubectl create secret docker-registry gitea-registry \
|
||||
--docker-server=gitea.coulomb.social \
|
||||
--docker-username=<gitea-user> \
|
||||
--docker-password=<package-token> \
|
||||
--namespace=<namespace>
|
||||
```
|
||||
|
||||
Reference it from workloads as `imagePullSecrets: [{name: gitea-registry}]`.
|
||||
|
||||
## Python Packages
|
||||
|
||||
The same Gitea package service is used for Python wheels. See
|
||||
`docs/gitea-package-registry.md` for the publish/install recipe and the
|
||||
`issue-core` migration notes from `RAILIANCE-WP-0004 I03`.
|
||||
|
||||
## Current Storage Notes
|
||||
|
||||
The live Gitea pod mounts `gitea-shared-storage` at `/data`; package blobs land
|
||||
under `/data/packages`. On 2026-05-19 that package directory was about 798.5 MiB.
|
||||
|
||||
The PVC is `default/gitea-shared-storage`, 10 GiB, `local-path`, `RWO`. The live
|
||||
cluster showed no Kubernetes `CronJob` backup resources across namespaces on
|
||||
2026-05-19. This is acceptable for the current smoke-test images, but heavy tag
|
||||
growth should wait for a platform backup/retention follow-up.
|
||||
Use `railiance-forge` for registry endpoints, package-token handling, smoke
|
||||
evidence, storage notes, retention posture, and future Forgejo registry
|
||||
ownership. Use `railiance-apps` only for S5 app release values and app runbooks
|
||||
that consume already-published images.
|
||||
|
||||
@@ -1,48 +1,16 @@
|
||||
# Gitea Package Registry
|
||||
|
||||
Gitea package support is enabled by `helm/gitea-registry-values.yaml`.
|
||||
That overlay is applied after the encrypted base values by
|
||||
`make gitea-deploy` and enables both container packages and Python
|
||||
packages.
|
||||
Canonical package-registry operating guidance now lives in:
|
||||
|
||||
## Python Packages
|
||||
|
||||
Publish Python wheels to the organization package endpoint:
|
||||
|
||||
```bash
|
||||
python -m build
|
||||
TWINE_USERNAME=<gitea-user> \
|
||||
TWINE_PASSWORD=<package-token> \
|
||||
python -m twine upload \
|
||||
--repository-url https://gitea.coulomb.social/api/packages/coulomb/pypi \
|
||||
dist/*
|
||||
```text
|
||||
/home/worsch/railiance-forge/docs/gitea-package-registry.md
|
||||
```
|
||||
|
||||
Install from the simple index:
|
||||
This compatibility pointer remains in `railiance-apps` while deploy-capable
|
||||
Gitea Helm, SOPS, and manifest files are still migrating under
|
||||
`RAILIANCE-WP-0006-T03`.
|
||||
|
||||
```bash
|
||||
pip install \
|
||||
--extra-index-url https://<gitea-user>:<package-token>@gitea.coulomb.social/api/packages/coulomb/pypi/simple/ \
|
||||
issue-core
|
||||
```
|
||||
|
||||
For CI, store the token as a secret and inject it into the package index
|
||||
URL at build time. Do not commit tokenized index URLs.
|
||||
|
||||
## issue-core Migration
|
||||
|
||||
The portable deployment path for `vergabe-teilnahme` is:
|
||||
|
||||
1. Release `issue-core` from its source repo as a wheel, for example
|
||||
`0.2.0`.
|
||||
2. Publish the wheel to the Gitea Python package registry.
|
||||
3. Change `vergabe-teilnahme/pyproject.toml` from the local path
|
||||
dependency to `issue-core>=0.2,<0.3`.
|
||||
4. Remove the Docker BuildKit `--build-context issue-core=...`
|
||||
requirement from image-build instructions.
|
||||
5. Build the image on a clean runner that has no sibling `issue-core`
|
||||
checkout.
|
||||
|
||||
Only the registry enablement lives in `railiance-apps`; the package
|
||||
release and application dependency change belong to the `issue-core` and
|
||||
`vergabe-teilnahme` repos.
|
||||
Use `railiance-forge` for the Gitea PyPI endpoint, package-token handling,
|
||||
publish/install recipes, retention posture, and future Forgejo package
|
||||
ownership. Use `railiance-apps` only for S5 app release values and app runbooks
|
||||
that consume already-published packages.
|
||||
|
||||
@@ -68,9 +68,10 @@ make vergabe-superuser # interactive createsuperuser
|
||||
|
||||
## Promoting a new image tag
|
||||
|
||||
1. Build + push from `vergabe-teilnahme` repo (see its `Dockerfile`
|
||||
header for the BuildKit `--build-context` invocation — see also
|
||||
`RAILIANCE-WP-0004 I03`).
|
||||
1. Build + push from the `vergabe-teilnahme` repo using the portable package
|
||||
path: `issue-core` must resolve from the Gitea PyPI registry, not from a
|
||||
sibling checkout. If `issue-core==0.2.0` is not published yet, keep
|
||||
`railiance-apps-WP-0004 I03` in `wait`.
|
||||
2. Update `image.tag` in `helm/vergabe-teilnahme-values.yaml` to the
|
||||
new git SHA.
|
||||
3. `make vergabe-deploy` — Helm rolls a new ReplicaSet with
|
||||
@@ -152,8 +153,8 @@ configuration belongs to `railiance-platform`).
|
||||
- Workplan: `workplans/railiance-apps-WP-0002-vergabe-teilnahme-on-railiance01.md`
|
||||
- Improvements backlog: `workplans/railiance-apps-WP-0004-app-deployment-improvements.md`
|
||||
- Shared DB cluster: `railiance-platform/docs/apps-pg.md`
|
||||
- Container registry: `docs/gitea-container-registry.md`
|
||||
- Python package registry: `docs/gitea-package-registry.md`
|
||||
- Container registry: `/home/worsch/railiance-forge/docs/gitea-container-registry.md`
|
||||
- Python package registry: `/home/worsch/railiance-forge/docs/gitea-package-registry.md`
|
||||
- Django deployment recipe: `docs/django-on-railiance.md`
|
||||
- Operator setup: `docs/operator-setup.md`
|
||||
- Operator recipes: `docs/operator-recipes.md`
|
||||
|
||||
Reference in New Issue
Block a user