Skip to content

Post receive fails when external issue tracker is set and commit message contains "Fixes #x"

I have an external issue tracker (Mantis) for one of my projects and since I've updated to 7.11.2 this morning I get some problems when pushing new commits.

Whenever a commit message contains Fixes #x (x being any number), GitLab tries to handle that message itself which fails because the project doesn't have its own issue tracker anymore.

From the sidekiq log:

2015-05-26_11:16:15.75576 2015-05-26T11:16:15.754Z 974 TID-baoh8 PostReceive JID- INFO: start
2015-05-26_11:16:15.82908 2015-05-26T11:16:15.828Z 974 TID-baoh8 PostReceive JID- INFO: fail: 0.074 sec
2015-05-26_11:16:15.83029 2015-05-26T11:16:15.830Z 974 TID-baoh8 WARN: {"class"=>"PostReceive", "args"=>["/var/opt/gitlab/git-data/repositories/ck/sandbox.git", "key-1",zNzVhNmQzNjA1M2VlYzZhNWI3MWZkMTZmZiA4YmJm\nYzZmYjY3YzI4ZGY0M2ZiNmUyZTEzZDNiMjFlNjA0MTQwODQ1IHJlZnMvaGVh\nZHMvbWFzdGVyCg==\n"]}
2015-05-26_11:16:15.83110 2015-05-26T11:16:15.830Z 974 TID-baoh8 WARN: undefined method `close' for #<ExternalIssue:0x0000000d125270>
2015-05-26_11:16:15.83140 2015-05-26T11:16:15.831Z 974 TID-baoh8 WARN: /opt/gitlab/embedded/service/gitlab-rails/app/services/issues/close_service.rb:4:in `execute'
2015-05-26_11:16:15.83143 /opt/gitlab/embedded/service/gitlab-rails/app/services/git_push_service.rb:87:in `block (2 levels) in process_commit_messages'
2015-05-26_11:16:15.83145 /opt/gitlab/embedded/service/gitlab-rails/app/services/git_push_service.rb:86:in `each'
2015-05-26_11:16:15.83145 /opt/gitlab/embedded/service/gitlab-rails/app/services/git_push_service.rb:86:in `block in process_commit_messages'
2015-05-26_11:16:15.83145 /opt/gitlab/embedded/service/gitlab-rails/app/services/git_push_service.rb:73:in `each'
2015-05-26_11:16:15.83146 /opt/gitlab/embedded/service/gitlab-rails/app/services/git_push_service.rb:73:in `process_commit_messages'
2015-05-26_11:16:15.83146 /opt/gitlab/embedded/service/gitlab-rails/app/services/git_push_service.rb:56:in `execute'
2015-05-26_11:16:15.83147 /opt/gitlab/embedded/service/gitlab-rails/app/workers/post_receive.rb:41:in `block in perform'
2015-05-26_11:16:15.83147 /opt/gitlab/embedded/service/gitlab-rails/app/workers/post_receive.rb:28:in `each'
2015-05-26_11:16:15.83149 /opt/gitlab/embedded/service/gitlab-rails/app/workers/post_receive.rb:28:in `perform'
2015-05-26_11:16:15.83149 /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/sidekiq-3.3.0/lib/sidekiq/processor.rb:75:in `execute_job'
2015-05-26_11:16:15.83150 /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/sidekiq-3.3.0/lib/sidekiq/processor.rb:52:in `block (2 levels) in process'
2015-05-26_11:16:15.83150 /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/sidekiq-3.3.0/lib/sidekiq/middleware/chain.rb:127:in `call'
2015-05-26_11:16:15.83150 /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/sidekiq-3.3.0/lib/sidekiq/middleware/chain.rb:127:in `block in invoke'
2015-05-26_11:16:15.83151 /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/sidekiq_middleware/memory_killer.rb:17:in `call'

This causes the whole job to fail and therefore I don't even get an entry in the activity feed.

The expected behavior would be to not call close at all when an external issue tracker is set. I'm pretty sure this worked in some way or another in 7.9.x