This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.
In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.
We've also updated the logic to be more systematic and less user-based.
Enable Get and Update of ci_default_git_depth for
Project API.
Renaming Project#default_git_depth to :ci_default_git_depth
to give more context through the API usage.
Add API documentation
Add spec for task_completion_status
Add test cases for task_completion_status result
Extracted shared samples
Add new spec file for task completion status response
Fix style errors
Add changelog entry
Changed samples to Hashes
Remove test for successful request
Remove not nil expectation
Add task_completion_status to api documentation for issues
Add task_completion_status to api documentation for merge_requests
Refactor spec so it just requests one specific item
Add task_completion_status to Taskable
Simplified task completion status in entities
Refactor spec so it separates status code check and content check
Fix spec description text and field name
This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.
In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.
We've also updated the logic to be more systematic and less user-based.
This extends POST#:id/repository/commits to allow the optional parameter
`:start_project`, which will allow targeting other projects besides the
one derived from `:id`.
Resolves https://gitlab.com/gitlab-org/gitlab-ce/issues/50850
The following EE files had small differences with their CE counterpart
so they have been ported to CE:
- doc/api/boards.md
- doc/api/discussions.md
- doc/api/notes.md
- doc/api/resource_label_events.md
- doc/api/services.md
Enabling GraphQL batch requests allows for multiple queries
to be sent in 1 request reducing the amount of requests
we send to the server.
Responses come come back in the same order as the queries were
provided.
When using the members/all api the same user was returned multiple times
when he was a member of the project/group and also of one of the
ancestor groups.
Now the member is returned only once giving priority to the membership
on the project and maintaining the same behaviour of the members UI.
* Cleaned issues and issues_statistics docs
* Renamed param with_labels_data to with_labels_details
* Added spec for N+1 check when retrieving labels from issue
* Refactoed CheckAssigneesCount validation class
Remove label_name and milestone_title params support
Add mutually_exclusive validation for author_id and author_username
Add mutually_exclusive validation for assignee_id and assignee_username
Add validation to allow single value for asignee_username on CE
Add separate issue_stats_params helper for statistics params and
reuse in issues_params.
If you can do this in the UI, you should be able to do it in the API. If
a discussion is not a single note discussion, or it is replyable, you
can reply to it.
Add env_var and file as supported types for CI variables. Variables of
type file expose to users existing gitlab-runner behaviour - save
variable value into a temp file and set the path to this file in an ENV
var named after the variable key.
Resolves https://gitlab.com/gitlab-org/gitlab-ce/issues/46806.
When this option is enabled, GitLab will create namespaces and service
accounts as usual. When disabled, GitLab wont create any project
specific kubernetes resources
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/56557