Noticed while reviewing #75.
giteaIssueService.Update reads opts.Title, opts.Body, opts.Assignees, and (after #75) opts.Labels, but never reads opts.Milestone. Same for Create. So forge issue edit <n> -m <milestone> and forge issue create -m <milestone> are silent no-ops against Gitea/Forgejo, the same class of bug #75 fixed for labels.
gitea.EditIssueOption and gitea.CreateIssueOption both have a Milestone *int64 field, so unlike labels this can go through the same call rather than a separate endpoint. It will need a title-to-ID resolver similar to resolveLabelIDs since UpdateIssueOpts.Milestone is a *string.
The github adapter handles this at github/issues.go:224.
Noticed while reviewing #75.
giteaIssueService.Updatereadsopts.Title,opts.Body,opts.Assignees, and (after #75)opts.Labels, but never readsopts.Milestone. Same forCreate. Soforge issue edit <n> -m <milestone>andforge issue create -m <milestone>are silent no-ops against Gitea/Forgejo, the same class of bug #75 fixed for labels.gitea.EditIssueOptionandgitea.CreateIssueOptionboth have aMilestone *int64field, so unlike labels this can go through the same call rather than a separate endpoint. It will need a title-to-ID resolver similar toresolveLabelIDssinceUpdateIssueOpts.Milestoneis a*string.The github adapter handles this at
github/issues.go:224.