[abhinavgautam01]

Closes #48

Notifications now carry the subject's number and web page, so consumers can link a notification to its issue or pull request without another API call. URL also means the same thing on every forge.

Changes to Notification

Field	Status	Contents
SubjectNumber	New	Issue, pull request or discussion number. 0 for other subjects such as commits and releases
RepoURL	New	Web page of the repository
URL	Changed on GitHub	Web page of the subject on every forge

Before this change GitHub set URL to the repository page while GitLab and Gitea set it to the subject page. RepoURL keeps the repository link available now that GitHub's URL points at the subject.

How each forge fills them

Forge	SubjectNumber	URL	RepoURL
GitHub	Parsed from Subject.URL	Built from the repository URL	Repository.HTMLURL
GitLab	Target.IID for issues and merge requests	TargetURL (unchanged)	TargetURL up to /-/
Gitea / Forgejo	Parsed from Subject.HTMLURL, falling back to Subject.URL	Subject.HTMLURL (unchanged)	Repository.HTMLURL

• GitHub only reports an API URL such as .../repos/octocat/hello/pulls/42. gitHubSubjectLink maps issues, pulls, discussions and commits to <repo>/issues/N, /pull/N, /discussions/N and /commit/<sha>. It builds on the repository's web URL, so GitHub Enterprise works without knowing the web host. Releases are addressed by ID rather than tag in the API, so their URL is left empty instead of guessed.
• GitLab todos don't include the project's web URL, but every project subpage lives under <project>/-/, so RepoURL is the part of TargetURL before that separator.
• Gitea / Forgejo numbers are only read for issue and pull subjects, from a path ending in /issues/N or /pulls/N.

Behaviour change

On GitHub, Notification.URL used to be the repository page and is now the subject page. Nothing in this repo reads it (the CLI doesn't print URL), but external callers relying on the old value should switch to RepoURL.

Tests

• The List tests for GitHub, GitLab and Gitea now check SubjectNumber, URL and RepoURL.
• TestGitHubSubjectLink covers issues, pull requests, discussions, commits, releases, GitHub Enterprise paths, a trailing slash on the repository URL, missing URLs, non-numeric IDs and non-repository paths.
• TestConvertGitLabTodoSubject covers merge requests in a subgroup, commits, epics and todos without a target.
• TestConvertGiteaNotificationSubject covers pulls, the API URL fallback, commits, repositories, non-numeric paths and missing URLs.
• go test -race ./..., go test -tags=tinygo ./gitlab, the js/wasip1 WebAssembly builds, the tinygo CI commands and golangci-lint v2.14.0 all pass locally.

[andrew]

Thanks, the GitHub and Gitea conversions look right. One thing before merge:

gitlab/notifications.go: RepoURL is taken from any TargetURL containing /-/, including targets that are not in a project. An epic todo with https://gitlab.com/groups/group/-/epics/3 gets RepoURL = https://gitlab.com/groups/group, a group page, while Repo stays empty because the todo has no Project. That contradicts the doc comment on Notification, which says RepoURL is the web page of the repository. Please only set RepoURL inside the if t.Project != nil block, and change the "epic keeps no number" test case to expect an empty RepoURL.

[abhinavgautam01]

Thanks, fixed. RepoURL is now only set inside the t.Project != nil block, so todos outside a project (like epics) leave it empty. The epic test case now expects an empty RepoURL, while the merge request and commit cases carry a Project so they still cover the URL derivation.

[andrew]

Thanks, that's the fix. Merging.