Merge service fails on update hook
Summary
An update
hook can fail under some circumstances when called by Gitlab's merge service, causing Gitlab to respond with a misleading "Conflicts detected during merge" message. This regression happened when Gitlab was updated from v10.x to v11.x. See "bug behavior" below for more details.
Steps to reproduce
- Create a personal access token for the Gitlab API.
- Create a repository with an
update
custom hook that makes a Gitlab API call. - Create any merge request in the repository and attempt to merge. The merge will fail with the message mentioned above.
(We also have merge approvals enabled on this repo. I'm not sure that's necessary to reproduce, though.)
Example Project
I don't believe that I can create a project with custom hooks on gitlab.com, as this requires filesystem access.
What is the current bug behavior?
When attempting to merge via the Gitlab web UI, a merge fails with the generic message "Conflicts detected during merge" on all merges, even those without merge conflicts. This was traced to the following line in merge_service.rb:78 (permalink to the current master HEAD).
What seems to be causing the issue is an update
hook in the custom_hooks
directory. With some super high-tech printf debugging, it was determined that the hook exits uncleanly at the following line when it makes a call to the Gitlab API.
groups=$(curl --silent --header "Private-Token: $key" https://<URL>/api/v4/groups?all_available=true)
(All instances of our server URL have been replaced with the text <URL>
but do note it's a valid URL with a valid certificate.)
However, this update
script worked fine with previous versions of Gitlab (v10.x and earlier). This line executes correctly at the command line. Also, manually merging and pushing using the command line works just fine, calling the update
hook correctly. I have to conclude that the update
script works fine under some circumstances, but not when called by Gitlab's merge service.
What is the expected correct behavior?
Merge should succeed after the update
hook finishes executing.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
System information System: Ubuntu 16.04 Proxy: no Current User: git Using RVM: no Ruby Version: 2.5.3p105 Gem Version: 2.7.6 Bundler Version:1.16.6 Rake Version: 12.3.1 Redis Version: 3.2.12 Git Version: 2.18.1 Sidekiq Version:5.2.3 Go Version: unknown
GitLab information Version: 11.6.4-ee Revision: 13e52b8 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: postgresql DB Version: 9.6.11 URL: https://URL HTTP Clone URL: https://URL/some-group/some-project.git SSH Clone URL: git@URL:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: google_oauth2
GitLab Shell Version: 8.4.3 Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks 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 >= 8.4.3 ? ... OK (8.4.3) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: 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: ... Checking Reply by email ...
IMAP server credentials are correct? ... yes Init.d configured correctly? ... skipped MailRoom running? ... skipped
Checking Reply by email ... Finished
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
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: ... 4/1 ... yes 8/2 ... yes 2/3 ... yes 8/4 ... yes 4/5 ... yes 5/6 ... yes 8/8 ... yes 4/9 ... yes 4/10 ... yes 4/11 ... yes 4/12 ... yes 18/13 ... yes 18/14 ... yes 12/15 ... yes 3/16 ... yes 4/17 ... yes 18/18 ... yes 5/19 ... yes 23/21 ... yes 26/22 ... yes 29/23 ... yes 4/24 ... yes 4/25 ... yes 12/26 ... yes 29/27 ... yes 12/28 ... yes 18/29 ... yes 37/30 ... yes 4/31 ... yes 4/32 ... yes 12/33 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.3.5 ? ... yes (2.5.3) Git version >= 2.18.0 ? ... yes (2.18.1) Git user has default SSH configuration? ... yes Active users: ... 42 Elasticsearch version 5.6 - 6.x? ... skipped (elasticsearch is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
Not really the responsible line, but it may be a useful starting point.