Preserve order when applying multiple scoped labels
What does this MR do?
See #207269 (closed)
When applying scoped labels, order matters. When the user adds two labels from the same set (say, workflowready for development and ~"workflow::In dev") the latter of the two is chosen and applied. This holds when labels are added using label_ids
(or related parameter add_label_ids
) however it's not true when using labels
(or related parameter add_labels
).
In the latter case labels are applied according to the order they're returned from the database, regardless of the order specified by the user. This is apparent when adding labels via the API, where inconsistent behaviour is observed.
It's also necessary to account for the case where the user adds labels via comma-separated string as well as by array, both are acceptable. So:
labels: ['workflow::start', 'workflow::end']
and
labels: 'workflow::start,workflow::end'
are both acceptable. That's why the line with .split(',')
looks for the parameter to be of String type.
Screenshots
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team