4 KiB
stage | group | info |
---|---|---|
Manage | Integrations | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments |
REST API deprecations and removals
The following API changes will occur when the v4 API is removed.
The date of this change is unknown. For details, see issue 216456 and issue 387485.
merged_by
API field
Breaking change. Related issue.
The merged_by
field in the merge request API
has been deprecated in favor of the merge_user
field which more correctly identifies who merged a merge request when
performing actions (merge when pipeline succeeds, add to merge train) other than a simple merge.
API users are encouraged to use the new merge_user
field instead. The merged_by
field will be removed in v5 of the GitLab REST API.
merge_status
API field
Breaking change. Related issue.
The merge_status
field in the merge request API
has been deprecated in favor of the detailed_merge_status
field which more correctly identifies
all of the potential statuses that a merge request can be in. API users are encouraged to use the
new detailed_merge_status
field instead. The merge_status
field will be removed in v5 of the GitLab REST API.
Single merge request changes API endpoint
Breaking change. Related issue.
The endpoint to get changes from a single merge request has been deprecated in favor the list merge request diffs endpoint. API users are encouraged to switch to the new diffs endpoint instead.
The changes from a single merge request
endpoint will be removed in v5 of the GitLab REST API.
Approvers and Approver Group fields in Merge Request Approval API
Breaking change. Related issue.
The endpoint to get the configuration of approvals for a project returns
empty arrays for approvers
and approval_groups
.
These fields were deprecated in favor of the endpoint to
get project-level rules
for a merge request. API users are encouraged to switch to this endpoint instead.
These fields will be removed from the get configuration
endpoint in v5 of the GitLab REST API.
Runner usage of active
replaced by paused
Breaking change. Related issue.
Occurrences of the active
identifier in the GitLab Runner GraphQL API endpoints will be
renamed to paused
in GitLab 16.0.
- In v4 of the REST API, starting in GitLab 14.8, you can use the
paused
property in place ofactive
- In v5 of the REST API, this change will affect endpoints taking or returning
active
property, such as:GET /runners
GET /runners/all
GET /runners/:id
/PUT /runners/:id
PUT --form "active=false" /runners/:runner_id
GET /projects/:id/runners
/POST /projects/:id/runners
GET /groups/:id/runners
The 16.0 release of GitLab Runner will start using the paused
property when registering runners.
Runner status will not return paused
Breaking change. Related issue.
In a future v5 of the REST API, the endpoints for GitLab Runner will not return paused
or active
.
A runner's status will only relate to runner contact status, such as:
online
, offline
, or not_connected
. Status paused
or active
will no longer appear.
When checking if a runner is paused
, API users are advised to check the boolean attribute
paused
to be true
instead. When checking if a runner is active
, check if paused
is false
.