git-pkgs/forge

This is rather an enhancement than a bug. To create a release you use forge release create --tag .... To upload release files you use forge upload <tag> .... Any reason why there is no --tag for upload? As much as I love direct params it is a bit of a fiddle if you want to automate it with a script for CI/CD. It would be great to if there would be the same param support across the board. Would make live much smoother.

Using forge against Forgejo to create releases results into vague or misleading error messages if things go wrong. The favorite errors are Error: Release has no Tag or Error: '' which are not very helpful. In most cases this happens if the TAG exists in the repository or a malformed tag is send. You can work around it by always delete the tag first or check if it exists but until you reach that point it took me a couple of iterations ;-) I haven't tracked it down further if this is a ForgeJo API issue or a forge wrapper issue. Might do it if time permits.

The forge APIs all support webhooks for real-time event delivery, but the library has no webhook support. Two possible scopes: Webhook management: Create/list/delete webhooks via the API (GitHub, GitLab, Gitea/Forgejo all have endpoints for this) Event parsing: Parse incoming webhook payloads into normalized event types, similar to how the library normalizes API responses across forges Event parsing would be particularly useful since each forge has its own webhook payload format and event names. A unified event type system would let consumers handle webhook events without forge-specific code. This could live alongside the existing polling-based NotificationService as an alternative real-time delivery mechanism.

The forge APIs support managing notification subscriptions (watch/unwatch repos, subscribe/unsubscribe/ignore threads) but the library doesn't expose this. GitHub: PUT /repos/{owner}/{repo}/subscription (watch repo), PUT /notifications/threads/{id}/subscription (subscribe/ignore thread) GitLab: subscription endpoints for projects and issues/MRs Gitea/Forgejo: PUT /repos/{owner}/{repo}/subscription (watch repo) This would allow consumers to programmatically mute/unmute notification threads and manage repo watch settings, syncing these preferences back to the forge rather than only tracking them locally.

The Notification struct doesn't include the subject's ID or number (e.g. issue number, PR number), even though the underlying forge APIs provide this information. GitHub: notification.Subject.URL contains /repos/owner/repo/issues/123 GitLab: todo.Target.IID is the issue/MR number directly Gitea/Forgejo: notification.Subject.HTMLURL contains the issue/PR number in the URL path Currently the conversion functions in github/notifications.go, gitlab/notifications.go, and gitea/notifications.go read the subject title and type but discard the subject URL and ID. Adding a SubjectID (or SubjectNumber) and SubjectURL field to the Notification struct would let consumers link notifications to their underlying issues/PRs without making additional API calls. The URL field is also inconsistent across forges: GitHub sets it to the repository HTML URL, while GitLab and Gitea set it to the subject URL. Having separate URL (subject web URL) and Repo fields would make this unambiguous.