Synchronize Merge Request Labels with Issue Labels if Merge Request was created from an Issue
Summary
When creating a Merge Request from an issue using the "Create Merge Request" button the MR inherits the issue's labels.
But when the issue's labels change the MR's labels are not updated accordingly.
Steps to reproduce
- Create a new project and enable issues feature (if necessary)
- Go to Issues | Boards
- Accept to use the proposed default lists: "To Do" and "Doing"
- Create a new issue in the "Open" list
- Drag the issue to "To Do" list --> label "To Do" is added to the issue
- Click on the issue's name to open the issue detail page
- Click "Create merge request" button --> MR with label "To Do" is created
- Go back to issue board
- Drag the issue to "Doing" list --> issue's labels are updated, "To Do" is removed, "Doing" is added
- Go back to the merge request --> It still has the label "To Do".
- Add a commit to the MR and merge it
Example Project
https://gitlab.com/heapifyman/mr-label-test/merge_requests?scope=all&utf8=%E2%9C%93&state=merged
What is the current bug behavior?
The MR keeps the label "To Do" although the MR is merged and the related issue is closed.
If you repeat steps 4 through 11 (even when omitting steps 8-10) you end up with a bunch of merged MRs which still have a brightly colored label "To Do".
This is confusing for the user because a merged MR and the label "To Do" contradict each other.
But this seems to be a quite usual dev workflow - at least the "create MR from issue" flow was kind of advertised by @williamchia at serverless architecture conference
This issue may be related to #17461 because the related issue's label "Doing" is also not removed.
This issue may be related to #24539. But from the description it was not clear to me if #24539 actually covers the same issue.
What is the expected correct behavior?
In Step 9, the MR's label "To Do" should be removed and the label "Doing" should be added. Like it happens with the related issue.
In Step 11, the MR's label "To Do" should be removed.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
But also on on-premise installation of GitLab CE.
Results of GitLab environment info
Expand for output related to GitLab environment info
System information System: Ubuntu 18.04 Current User: git Using RVM: no Ruby Version: 2.6.3p62 Gem Version: 2.7.9 Bundler Version:1.17.3 Rake Version: 12.3.2 Redis Version: 3.2.12 Git Version: 2.22.0 Sidekiq Version:5.2.7 Go Version: unknown
GitLab information Version: 12.3.5 Revision: 2417d5becc7 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 10.7 URL: https://gitlab.my-domain.com HTTP Clone URL: https://gitlab.my-domain.com/some-group/some-project.git SSH Clone URL: ssh://git@gitlab.my-domain.com:2223/some-group/some-project.git Using LDAP: yes Using Omniauth: yes Omniauth Providers: crowd
GitLab Shell Version: 10.0.0 Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
Expand for output related to the GitLab application check
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 10.0.0 ? ... OK (10.0.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Redis available via internal API: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain LDAP authentication... Success LDAP users with access to your GitLab server (only showing the first 100 results) User output sanitized. Found 100 users of 100 limit.
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) Projects have namespace: ... 9/7 ... yes 5/8 ... yes 5/9 ... yes 5/10 ... yes 5/11 ... yes 5/12 ... yes 5/13 ... yes 14/15 ... yes 5/16 ... yes 14/17 ... yes 20/18 ... yes 33/22 ... yes 14/23 ... yes 27/24 ... yes 29/25 ... yes 29/26 ... yes 29/27 ... yes 29/28 ... yes 5/29 ... yes 5/30 ... yes 5/31 ... yes 5/32 ... yes 5/33 ... yes 31/35 ... yes 29/36 ... yes 29/37 ... yes 29/38 ... yes 5/39 ... yes 5/40 ... yes 5/41 ... yes 34/42 ... yes 29/43 ... yes 5/45 ... yes 5/46 ... yes 5/48 ... yes 5/49 ... yes 5/50 ... yes 35/51 ... yes 35/52 ... yes 35/53 ... yes 35/54 ... yes 35/55 ... yes 35/56 ... yes 35/57 ... yes 35/58 ... yes 35/59 ... yes 5/60 ... yes 36/62 ... yes 36/63 ... yes 39/65 ... yes 41/67 ... yes 42/68 ... yes 41/69 ... yes 41/70 ... yes 17/71 ... yes 42/72 ... yes 35/73 ... yes 41/74 ... yes 53/75 ... yes 53/76 ... yes 53/77 ... yes 35/78 ... yes 31/79 ... yes 42/81 ... yes 42/84 ... yes 43/85 ... yes 5/86 ... yes 42/88 ... yes 42/89 ... yes 35/90 ... yes 35/91 ... yes 5/92 ... yes 35/93 ... yes 35/94 ... yes 45/95 ... yes 31/96 ... yes 35/97 ... yes 14/98 ... yes 50/99 ... yes 51/102 ... yes 31/103 ... yes 52/104 ... yes 31/105 ... yes 52/106 ... yes 55/107 ... yes 55/108 ... yes 5/109 ... yes 42/110 ... yes 55/111 ... yes 31/112 ... yes 55/114 ... yes 31/115 ... yes 55/116 ... yes 55/117 ... yes 52/118 ... yes 45/119 ... yes 55/120 ... yes 64/121 ... yes 64/122 ... yes 64/123 ... yes 55/124 ... yes 64/125 ... yes 5/126 ... yes 55/127 ... yes 36/128 ... yes 55/129 ... yes 55/130 ... yes 35/131 ... yes 55/132 ... yes 42/133 ... yes 66/134 ... yes 67/136 ... yes 67/137 ... yes 67/138 ... yes 55/139 ... yes 55/140 ... yes 52/141 ... yes 42/142 ... yes 71/143 ... yes 71/144 ... yes 73/147 ... yes 74/148 ... yes 55/149 ... yes 52/150 ... yes 52/151 ... yes 52/152 ... yes 52/153 ... yes 52/154 ... yes 52/155 ... yes 52/156 ... yes 52/157 ... yes 52/158 ... yes 52/159 ... yes 52/160 ... yes 5/161 ... yes 52/162 ... yes 52/163 ... yes 52/164 ... yes 72/165 ... yes 2/166 ... yes 66/167 ... yes 69/168 ... yes 69/170 ... yes 69/172 ... yes 86/173 ... yes 86/174 ... yes 86/175 ... yes 86/177 ... yes 86/178 ... yes 72/179 ... yes 86/180 ... yes 73/181 ... yes 73/182 ... yes 5/184 ... yes 69/186 ... yes 87/188 ... yes 87/189 ... yes 88/190 ... yes 73/191 ... yes 2/192 ... yes 86/193 ... yes 52/194 ... yes 52/195 ... yes 71/196 ... yes 73/197 ... yes 86/199 ... yes 64/200 ... yes 88/201 ... yes 50/202 ... yes 87/203 ... yes 95/204 ... yes 52/205 ... yes 2/206 ... yes 74/207 ... yes 29/208 ... yes 74/209 ... yes 74/210 ... yes 72/211 ... yes 5/212 ... yes 5/213 ... yes 67/214 ... yes 5/215 ... yes 88/216 ... yes 72/217 ... yes 86/218 ... yes 86/219 ... yes 86/220 ... yes 35/221 ... yes 29/222 ... yes 52/223 ... yes 52/225 ... yes 35/226 ... yes 86/227 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.5.3 ? ... yes (2.6.3) Git version >= 2.22.0 ? ... yes (2.22.0) Git user has default SSH configuration? ... yes Active users: ... 40 Is authorized keys file accessible? ... yes
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished