Avatar URL not working with Carrierwave 1.0.0

[connorshea]

After testing carrierwave 1.0.0.beta with GitLab, the entire test suite passes except for one test (our app is pretty huge, so this is commendable!).

I suspected that #1481 might be the culprit, so I bisected the commits down to 04003e4 (success) and d42bc52 (failure), which means that #1481 is most definitely the problem here.

The specific failing spec is this (actual source file here):

describe '#avatar_url' do
  subject { project.avatar_url }

  let(:project) { create(:project) }

  context 'When avatar file is uploaded' do
    before do
      project.update_columns(avatar: 'uploads/avatar.png')
      allow(project.avatar).to receive(:present?) { true }
    end

    let(:avatar_path) do
      "/uploads/project/avatar/#{project.id}/uploads/avatar.png"
    end

    it { should eq "http://localhost#{avatar_path}" }
  end
end

avatar_url is defined in our project.rb model as follows (I removed one else statement since that code path isn't being exercised here and is unrelated to Carrierwave):

def avatar_url
  if self[:avatar].present?
    [gitlab_config.url, avatar.url].join
  end
end

Before (behavior in 0.10.0 and 04003e4): /uploads/project/avatar/1/uploads/avatar.png

After (behavior in 1.0.0.beta and d42bc52): An empty string

(The above URL seems to be produced by "uploads/#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}" in our avatar_uploader.rb if that matters)

Here's the specific build where the test fails on 1.0.0.beta: https://gitlab.com/gitlab-org/gitlab-ce/builds/4505244

Hopefully this helps, I'd like to get this resolved if we can. Please ask if there's anything I've left unclear or if I can do anything to help. Thanks!

[connorshea]

Looks like #1855 may be related since the problem-case is generated by exactly the same method.

[mshibuya]

I couldn't get the point for a long time but I finally found out, please don't do #update_columns since it will make the attribute value and uploaders out of sync.
Slightly related issue is discussed in #2253.