1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
|
# Labels
## Overview
Labels allow you to categorize epics, issues, and merge requests using descriptive titles like
`bug`, `feature request`, or `docs`, as well as customizable colors. They allow you to quickly
and dynamically filter and manage epics, issues, and merge requests, and are a key
part of [issue boards](issue_board.md).
You can use labels to help [search](../search/index.md#issues-and-merge-requests) in
lists of issues, merge requests, and epics, as well as [search in issue boards](../search/index.md#issue-boards).
## Project labels and group labels
There are two types of labels in GitLab:
- **Project labels** can be assigned to issues and merge requests in that project only.
- **Group labels** can be assigned to issues and merge requests in any project in
the selected group or its subgroups.
- They can also be assigned to epics in the selected group or its subgroups.**(ULTIMATE)**
## Assign and unassign labels
Every issue, merge request and epic can be assigned any number of labels. The labels are
managed in the right sidebar, where you can assign or unassign labels as needed.
To assign a label to an issue, merge request or epic:
1. In the label section of the sidebar, click **Edit**, then:
- In the list, click the labels you want. Each label is flagged with a checkmark.
- Find labels by entering a search query and clicking search (**{search}**), then
click on them. You can search repeatedly and add more labels.
1. Click **X** or anywhere outside the label section and the labels are applied.
You can also assign a label with the [`/assign @username` quick action](quick_actions.md).
## Label management
Users with a [permission level](../permissions.md) of Reporter or higher are able to create
and edit labels.
### Project labels
View the project labels list by going to the project and clicking **Issues > Labels**.
The list includes all labels that are defined at the project level, as well as all
labels inherited from the parent group. You can filter the list by entering a search
query at the top and clicking search (**{search}**).
To create a new project label:
1. Navigate to **Issues > Labels** in the project.
1. Click the **New label** button.
- Enter the title.
- (Optional) Enter a description.
- (Optional) Select a background color by clicking on the available colors, or input
a hex color value for a specific color.
1. Click **Create label** to create the label.
You can also create a new project label from within an issue or merge request. In the
label section of the right sidebar of an issue or a merge request:
1. Click **Edit**.
1. Click **Create project label**.
- Fill in the name field. Note that you can't specify a description if creating a label
this way. You can add a description later by editing the label (see below).
- (Optional) Select a color by clicking on the available colors, or input a hex
color value for a specific color.
1. Click **Create**.
Once created, you can edit a label by clicking the pencil (**{pencil}**), or delete
a label by clicking the three dots (**{ellipsis_v}**) next to the **Subscribe** button
and selecting **Delete**.
#### Promote a project label to a group label
If you previously created a project label and now want to make it available for other
projects within the same group, you can promote it to a group label. If other projects
in the same group have a label with the same name, they will all be overwritten by
the new group label.
WARNING: **Caution:**
Promoting a label is a permanent action, and cannot be reversed.
To promote a project label to a group label:
1. Navigate to **Issues > Labels** in the project.
1. Click on the three dots (**{ellipsis_v}**) next to the **Subscribe** button and
select **Promote to group label**.
### Group labels
View the group labels list by going to the group and clicking **Issues > Labels**.
The list includes all labels that are defined at the group level only. It does not
list any labels that are defined in projects. You can filter the list by entering
a search query at the top and clicking search (**{search}**).
To create a **group label**, navigate to **Issues > Labels** in the group and
follow the same process as [creating a project label](#project-labels).
#### Create group labels from epics **(ULTIMATE)**
You can create group labels from the Epic sidebar. The labels you create will
belong to the immediate group to which the epic belongs. The process is the same as
creating a [project label from an issue or merge request](#project-labels).
### Generate default labels
If a project or group has no labels, you can generate a default set of project or group
labels from the label list page. The page will show a **Generate a default set of labels**
button if the list is empty, and clicking it will add the following default labels
to the project:
- `bug`
- `confirmed`
- `critical`
- `discussion`
- `documentation`
- `enhancement`
- `suggestion`
- `support`
## Scoped labels **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9175) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
Scoped labels allow teams to use the label feature to annotate issues, merge requests
and epics with mutually exclusive labels. This can enable more complicated workflows
by preventing certain labels from being used together.
A label is scoped when it uses a special double-colon (`::`) syntax in the label’s
title, for example:
An issue, merge request or epic cannot have two scoped labels, of the form `key::value`,
with the same `key`. Adding a new label with the same `key`, but a different `value` will
cause the previous `key` label to be replaced with the new label.
Example use case:
1. An issue is identified as being low priority, and a `priority::low` project
label is added to it.
1. After more review the issue priority is increased, and a `priority::high` label is
added.
1. GitLab automatically removes the `priority::low` label, as an issue should not
have two priority labels at the same time.
### Workflows with scoped labels
Suppose you wanted a custom field in issues to track the operating system platform
that your features target, where each issue should only target one platform. You
would then create three labels `platform::iOS`, `platform::Android`, `platform::Linux`.
Applying any one of these labels on a given issue would automatically remove any other
existing label that starts with `platform::`.
The same pattern could be applied to represent the workflow states of your teams.
Suppose you have the labels `workflow::development`, `workflow::review`, and
`workflow::deployed`. If an issue already has the label `workflow::development`
applied, and a developer wanted to advance the issue to `workflow::review`, they
would simply apply that label, and the `workflow::development` label would
automatically be removed. This behavior already exists when you move issues
across label lists in an [issue board](issue_board.md#creating-workflows), but
now, team members who may not be working in an issue board directly would still
be able to advance workflow states consistently in issues themselves.
This functionality is demonstrated in a video regarding
[using scoped labels for custom fields and workflows](https://www.youtube.com/watch?v=4BCBby6du3c).
### Scoped labels with nested scopes
You can create a label with a nested scope by using multiple double colons `::` when creating
it. In this case, everything before the last `::` will be the scope.
For example, `workflow::backend::review` and `workflow::backend::development` are valid
scoped labels, but they **can't** exist on the same issue at the same time, as they
both share the same scope, `workflow::backend`.
Addtionally, `workflow::backend::review` and `workflow::frontend::review` are valid
scoped labels, and they **can** exist on the same issue at the same time, as they
both have different scopes, `workflow::frontend` and `workflow::backend`.
## Subscribing to labels
From the project label list page and the group label list page, you can click **Subscribe**
to the right of any label to enable [notifications](../profile/notifications.md) for that
label. You will be notified whenever the label is assigned to an epic,
issue, or merge request.
If you are subscribing to a group label from within a project, you can select to subscribe
to label notifications for the project only, or the whole group.
## Label priority
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/14189) in GitLab 8.9.
> - Priority sorting is based on the highest priority label only. [This discussion](https://gitlab.com/gitlab-org/gitlab/issues/14523) considers changing this.
Labels can have relative priorities, which are used in the **Label priority** and
**Priority** sort orders of the epic, issue, and merge request list pages. Prioritization
for both group and project labels happens at the project level, and cannot be done
from the group label list.
From the project label list page, star a label to indicate that it has a priority.
Drag starred labels up and down the list to change their priority, where higher in the list
means higher priority.
On the epic, merge request, and issue list pages, for both groups and projects, you
can sort by `Label priority` or `Priority`.
If you sort by `Label priority`, GitLab uses this sort comparison order:
1. Items with a higher priority label.
1. Items without a prioritized label.
Ties are broken arbitrarily. Note that only the highest prioritized label is checked,
and labels with a lower priority are ignored. See this [related issue](https://gitlab.com/gitlab-org/gitlab/issues/14523)
for more information.
If you sort by `Priority`, GitLab uses this sort comparison order:
1. Items with milestones that have due dates, where the soonest assigned [milestone](milestones/index.md)
is listed first.
1. Items with milestones with no due dates.
1. Items with a higher priority label.
1. Items without a prioritized label.
Ties are broken arbitrarily.
|
