cmd: unify gitea client construction behind ctx-based service constructors #192
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea#192
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Tidiness follow-up from the separation-of-concerns audit (no logic leak involved):
~14
cmdpackages callgitea.NewClient(ctx)only to immediately hand the client to aservice.NewXxxService(client)constructor (e.g.internal/cmd/issue/sub.go:18,lock.go:40,time.go:17,comment_extra.go:27). This is whycmd -> giteaedges look noisy in the raw import graph, and it is inconsistent with the cleaner ctx-basedservice.NewServices(ctx)pattern already used a few lines away (internal/cmd/issue/sub.go:99), which hides gitea construction entirely.Acceptance criteria:
cmdpackages obtain services via ctx-based constructors; directgitea.NewClientcalls incmddrop to the few places that genuinely need the raw client (e.g. the sanctionedapipassthrough).giteaimport disappears from mostcmdpackages; import graph reflects it.Cosmetic/low priority - worth doing opportunistically, not urgently.