generated from coulomb/repo-seed
92 lines
3.3 KiB
Markdown
92 lines
3.3 KiB
Markdown
---
|
|
id: ISSUE-WP-0002
|
|
type: workplan
|
|
title: "Publish issue-core to Gitea PyPI"
|
|
domain: custodian
|
|
repo: issue-core
|
|
status: finished
|
|
owner: codex
|
|
topic_slug: custodian
|
|
created: "2026-05-23"
|
|
updated: "2026-06-05"
|
|
state_hub_workstream_id: "87a5dcb6-5b2c-4d3f-8d5c-e265889b0fc6"
|
|
---
|
|
|
|
# Publish issue-core to Gitea PyPI
|
|
|
|
`issue-core` needs a first real Python package release in the Coulomb Gitea
|
|
package registry so downstream applications can depend on a versioned package
|
|
instead of a sibling checkout path.
|
|
|
|
## Publish and verify the Gitea PyPI package
|
|
|
|
```task
|
|
id: ISSUE-WP-0002-T01
|
|
status: done
|
|
priority: high
|
|
state_hub_task_id: "f0df7dbc-b55d-4835-a528-f44a329efb0e"
|
|
```
|
|
|
|
**Problem.** `vergabe-teilnahme` and future Railiance S5 apps need
|
|
`issue-core` as a normal package dependency. A local dependency such as
|
|
`issue-core @ file:///home/worsch/issue-core` makes Docker builds depend on a
|
|
specific operator workstation and forces non-portable BuildKit named contexts.
|
|
|
|
**Current state.** The repo has package release plumbing prepared:
|
|
|
|
- `make package-check` builds and validates `issue-core==0.2.0`.
|
|
- `make publish-gitea` uploads `dist/*` to the Coulomb Gitea PyPI endpoint.
|
|
- `.gitea/workflows/publish-python-package.yml` can publish on `v*` tags once
|
|
package registry secrets exist.
|
|
- `docs/package-release.md` documents local and tag-based publishing.
|
|
|
|
**Resolved blocker.** Publishing required a Gitea package username/token with
|
|
permission to upload to:
|
|
|
|
```text
|
|
https://gitea.coulomb.social/api/packages/coulomb/pypi
|
|
```
|
|
|
|
The package was published on 2026-06-05 using the operator-provided token from
|
|
`/tmp/gat.tmp`; the token value was not written to repo files or command logs.
|
|
|
|
**Implementation steps.**
|
|
|
|
1. Configure Gitea repository or organization secrets:
|
|
`GITEA_PACKAGE_USER` and `GITEA_PACKAGE_TOKEN`.
|
|
2. Publish `issue-core==0.2.0` either by pushing tag `v0.2.0` or by running:
|
|
|
|
```bash
|
|
TWINE_USERNAME=<gitea-user> \
|
|
TWINE_PASSWORD=<package-token> \
|
|
make publish-gitea
|
|
```
|
|
|
|
3. Verify the simple index exposes the package:
|
|
|
|
```bash
|
|
curl -fsS https://gitea.coulomb.social/api/packages/coulomb/pypi/simple/issue-core/
|
|
```
|
|
|
|
4. Verify a clean environment can install the package from the Gitea simple
|
|
index with credentials injected outside Git.
|
|
5. Coordinate with `vergabe-teilnahme` to regenerate its `uv.lock` from the
|
|
published package and confirm its Docker build no longer needs the sibling
|
|
`issue-core` checkout.
|
|
|
|
**Done when.**
|
|
|
|
- `issue-core==0.2.0` is visible in the Coulomb Gitea PyPI simple index.
|
|
- A clean Python environment can install `issue-core>=0.2,<0.3` from Gitea.
|
|
- The publish workflow has the required secrets and a documented release path.
|
|
- The Railiance app deployment blocker can be closed without relying on local
|
|
path dependencies.
|
|
|
|
**Completed 2026-06-05.** Built and checked `issue-core==0.2.0`, published the
|
|
wheel and source distribution to the Coulomb Gitea PyPI registry as `tegwick`
|
|
through a temporary local Kubernetes port-forward, then exposed the approved
|
|
public `/api/packages` ingress route from `railiance-forge`. The public
|
|
package-specific simple index returns `200`, a clean temporary environment can
|
|
install `issue-core==0.2.0` from Gitea, and `vergabe-teilnahme/uv.lock` now
|
|
resolves `issue-core` from the Gitea registry instead of a sibling checkout.
|