- Update github.com/xanzy/go-gitlab from v0.93.0 to v0.101.0
- Update rebase MR functions to use RebaseMergeRequestOptions for setting the "skip_ci" field
- Update all request options to use the LabelOptions type
- Replace deprecated gitlab.{String,Int,Bool,etc} functions with gitlab.Ptr
Fixes#7504
Signed-off-by: Justen Stall <justenstall@gmail.com>
feat: Make mr create prompt for reviewers
Closes#1339
See merge request https://gitlab.com/gitlab-org/cli/-/merge_requests/1275
Merged-by: Gary Holtz <gholtz@gitlab.com>
Approved-by: Gary Holtz <gholtz@gitlab.com>
Approved-by: James Liu <jliu@gitlab.com>
Co-authored-by: Benedek Thaler <thaler@thaler.hu>
Currently the check-update command which checks for
latest glab releases, checks from the releases page
of the old GitHub repo.
This MR changes this behaviour to check releases
from the new gitlab-org/cli repo.
* feat(git): Allow for overriding the TopLevelDir
This would allow us to use a different output for this command in tests.
Issue #923
* fix: Don't show non-templates when asking chosing
In cases where users have non template files in the .gitlab/[template]/
folder they might will be picked up and displayed.
This fixes that by filtering out all the files that are hidden and don't
end in .md
Issue #923
* feat(cmdutils): Sort templates in alphabetical order
When creating issues we prompted only project milestones. This would
break workflows where group milestones were used.
They are two different APIs so we have to normalize their output and
merge it to one.
Issue #698
This adds merge options when merging an MR. The user is given three merge options
- create merge commit
- squash and merge
- rebase and merge
NB: This options are only available on TTYs. On non-ttys, the default is to create a merge commit unless the user explicitly specifies the merge method using the available flag options
- Don't cache stuff anymore, Network requests are not very time
consuming.
- If no labels are defined in the project then prompt the user to define
them via a comma-separated list of strings, otherwise present the
defined ones to the user.
When GITLAB_HOST or GITLAB_URI has been set, we resolve only local remotes that match the set hostname.
With this in place, a heterogeneous mix of hosts in a local remote file will not cause GITLAB_HOST to be ignored.
An error is returned if the hostname specified in GITLAB_HOST is not present in the local remotes.