Skip to content

"Error Loading viewer" when accessing projects imported by rake-task in Firefox Nightly.

Summary

Trying to access any git projects that are under a group created by a rake task will have issues displaying correctly when accessed from the web in firefox nightly.

Steps to reproduce

  1. Create a bare git repo with a couple of commits (BAR). Make sure there's a file to read somewhere.

  2. Import BAR into gitlab using the rake task.

  • Make sure there's a group directory available
  • ex: gitlab-rake gitlab:import:repos['/var/opt/gitlab/git-data/repository-import']
    • where repository-import has FOO under it, and BAR goes into FOO

  1. Make another project (BAZ) from the web interface (I used firefox nightly) and make sure it's created under the FOO group.

  2. Any files already in the BAR OR BAZ project will not be able to be shown in the web interface on firefox nightly.

  • Structure looks like so after importing and creating the 2 projects:
gitlab.company.com/FOO/BAR.git
gitlab.company.com/FOO/BAZ.git

What is the current bug behavior?

Firefox can't display any file preview contents (or commit data) in the web interface when the project resides under a group created by the import rake task.

Not_working

(from left to right: Firefox Nightly, Google Chrome, Internet Explorer)

What is the expected correct behavior?

I should be able to see the preview contents as well as the commit data when using Gitlabs web interface with Firefox.

working

(from left to right: Firefox Nightly, Google Chrome, Internet Explorer)

Relevant logs and/or screenshots

Also to note: I'm running Gitlab using docker-compose. relevant docker-compose.yml:

version: '3.6'
services:
  gitlab:
    image: 'gitlab/gitlab-ce:10.7.3-ce.0'
    restart: always
    hostname: 'gitlab.company.com'
    # the stuff after the :- indicate default values if the environment variable is
    # not found OR not set. The environment variable is defined in /etc/environment
    container_name: ${GITLAB_WEB_CONTAINER_NAME:-company_gitlab}
    ports:
      # If non-standard ports, make sure they match the values in config/gitlab.rb
      - "80:80"
      - "443:443"
      - "44022:22"
      # prometheus monitoring point
      - "44090:9090"
    volumes:
      - '/mnt/docker/gitlab/web/config:/etc/gitlab:rw'
      - '/mnt/docker/gitlab/web/logs:/var/log/gitlab:rw'
      - '/mnt/bk:/var/opt/gitlab/backups:rw'
      - '/mnt/docker/gitlab/web/import:/var/opt/gitlab/git-data/repository-import/FOO:rw'

More configuration is done in the gitlab.rb file which I can post the relevant parts of, but will take some time to edit out the sensitive information.

Nightly Version: 61.0a1 (2018-05-04) (64-bit)

Windows Version

Output of checks

This does not happen on Gitlab.com

Results of GitLab environment info

System information
System:
Current User:   git
Using RVM:      no
Ruby Version:   2.3.6p384
Gem Version:    2.6.13
Bundler Version:1.13.7
Rake Version:   12.3.0
Redis Version:  3.2.11
Git Version:    2.14.3
Sidekiq Version:5.0.5
Go Version:     unknown


GitLab information
Version:        10.7.3
Revision:       2555d6c
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
URL:            https://gitlab.company.com
HTTP Clone URL: https://gitlab.company.com/some-group/some-project.git
SSH Clone URL:  ssh://git@gitlab.wsfsfc.net:44022/some-group/some-project.git
Using LDAP:     yes
Using Omniauth: no


GitLab Shell
Version:        7.1.2
Repository storage paths:
  • default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab Shell ...

GitLab Shell version >= 7.1.2 ? ... OK (7.1.2)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
3/1 ... ok
3/2 ... ok
3/3 ... ok
3/4 ... ok
3/5 ... ok
3/6 ... ok
3/7 ... ok
3/8 ... ok
3/9 ... ok
3/10 ... ok
1/11 ... ok
3/12 ... ok
3/13 ... ok
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 Sidekiq ...


Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Reply by email is disabled in config/gitlab.yml
Checking LDAP ...


Server: [redacted]
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
[ . . . Redacted . . . ]
Checking LDAP ... Finished


Checking GitLab ...


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? ... skipped (no tmp uploads folder yet)
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: ...
3/1 ... yes
3/2 ... yes
3/3 ... yes
3/4 ... yes
3/5 ... yes
3/6 ... yes
3/7 ... yes
3/8 ... yes
3/9 ... yes
3/10 ... yes
1/11 ... yes
3/12 ... yes
3/13 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.3.6)
Git version >= 2.9.5 ? ... yes (2.14.3)
Git user has default SSH configuration? ... yes
Active users: ... 2


Checking GitLab ... Finished