Thore CimbalandClaude Opus 5
6fb3cb7fed
#0055 is done: ThreadNet-Web be323ed checks in an .npmrc binding @sorb to rohana. The bump that mattered was not the file but what upstream's .gitignore does with it - it ignores /.npmrc, so the naive fix would have stayed local while CI kept resolving against npmjs. Measured in an isolated tree: without the file pnpm goes to npmjs and fails, with it the scope resolves to rohana at the integrity hash the lockfile already carries, and with rohana unreachable the install fails instead of falling back. threadnet-call only publishes and already sets the scope in its own CI; gitops never touches it. ThreadNet-Web was the only consumer. Four issues no longer describe reality, each verified rather than assumed: - #0091 (gitops#61) was fixed when it was written - on_conflict: fail shipped in ef04d86 and the MAS pod has run that config since 2026-08-11T14:08:41Z. Its one deliberate remainder became #0043, which is closed and verified live. - #0079 (gitops#46) asked for the Gitea migration and a central view. The migration ran; the central view was decided the other way round - repo canonical, GitLab mirrored (ADR-0012/0019) - which also answers the reachability trade-off it left open, and better than its three options did. - #0075 (gitops#40) is rejected, not done: it wanted new issues to appear in the Gitea kanban automatically. Issues no longer live in Gitea and the board is script-written. Nothing was accomplished; the question dissolved. - #0098 is a rollout record whose only remainder, the macOS build, is #0022. Three AARs move to harvested - every open item in them is tracked as an issue. Checked and still accurate, so left alone: the wiki branch still exists on both remotes (#0019), docs/TASKS.md and oldwiki/ are still there (#0085), element-web-docs still names live resources (#0086), res/themes/element persists (#0100), only WIKI_CANONIZE_TOKEN is set so TURN rotation still lacks its token (#0084), gameserver still has zero push mirrors (#0032), the broken .6 package is still published (#0101), and options.ts still builds simulcast layers regardless of codec, which is what blocks VP9 (#0057). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
---
|
|
type: issue
|
|
id: "0075"
|
|
status: rejected
|
|
created: 2026-07-28
|
|
milestone: M2
|
|
priority: low
|
|
area: infrastructure
|
|
projekt: gitops
|
|
gitlab_iid: "40"
|
|
related: []
|
|
---
|
|
# Neue Issues erscheinen nicht automatisch im Gitea-Kanban/Projects-Board
|
|
|
|
> Adoptiert aus [gitops#40](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/40) (2026-08-18, ADR-0019). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei.
|
|
|
|
Gitea bietet aktuell keine REST-API fuer Projects/Kanban-Boards (bestaetigt mit 4 verschiedenen Tokens, darunter ein Full-Admin-Token - durchgehend 404). Das ist keine Berechtigungsfrage auf unserer Seite, sondern eine tatsaechlich fehlende Upstream-Funktion (siehe Gitea GitHub Issue #36824, offenes Feature-Request, Stand 2026-07-28 noch nicht implementiert).
|
|
|
|
Konkrete Auswirkung: Neu erstellte Issues (#11-#39, per Batch-Script aus dem alten TASKS.md-Backlog migriert) landen nicht automatisch im bestehenden Kanban/Projects-Board der Roadmap - muessen manuell per Drag&Drop/UI hinzugefuegt werden.
|
|
|
|
Optionen fuer die Zukunft:
|
|
- Manuell nachpflegen (aktueller Stand)
|
|
- Auf ein Gitea-Update warten, falls die Projects-API implementiert wird
|
|
- Alternatives Board-Tool evaluieren, falls das dauerhaft zu nervig wird
|
|
|
|
Niedrige Prioritaet, da rein organisatorisch - kein technisches Risiko.
|
|
|
|
---
|
|
*Migriert aus Gitea `sorb/axion1337.chat-gitops#40` — dort erstellt am 2026-07-28 von sorb.*
|
|
<!-- gitea-migration: sorb/axion1337.chat-gitops#40 -->
|
|
|
|
## Gegenstandslos — Relevanz-Durchgang 2026-08-18
|
|
|
|
Die Voraussetzung des Issues gibt es nicht mehr. Es beschreibt, dass neue Issues
|
|
nicht automatisch im **Gitea**-Kanban landen, weil Gitea keine Projects-API hat.
|
|
Inzwischen liegen die Issues weder in Gitea noch primär in einem Board: kanonisch
|
|
ist `docs/issues/` im management-Repo, und die Board-Ansicht auf GitLab wird von
|
|
`scripts/spiegel_issues.py` deterministisch beschrieben — genau die Automatik, die
|
|
hier gefehlt hat, nur an einer anderen Stelle
|
|
([ADR-0012](../adr/0012-issues-im-repo-gitlab-als-spiegel.md),
|
|
[ADR-0019](../adr/0019-komponenten-issues-adoptiert.md)).
|
|
|
|
Die fehlende Gitea-API ist damit kein Mangel mehr, sondern irrelevant. Kein
|
|
Aufwand offen, nichts zu tun — deshalb `rejected` statt `done`: erledigt wurde
|
|
hier nichts, die Frage hat sich aufgelöst.
|