Gitlab 10.7 WebIDE does not work

I just updated our on-prem Gitlab instance with the new 10.7 release. We have the EE omnibus package installed without any license key, so we are using CE features.

I went to check out the new Web IDE feature that is now included with CE in 10.7 and every time I attempt to open it, I receive the following error:

Error while loading the project data. Please try again.

I have tried

  • gitlab-ctl restart
  • Opening it in a private browsing tab
  • Opening files from various projects

Anyone have any suggestions on where I can start in troubleshooting this? I checked the logs in /var/logs/gitlab/gitlab-rails and /var/logs/gitlab/unicorn and I couldn’t find any related messages.
Is there a different log file I should be looking in?
Is there something else I can look at?


I appears that this is being caused by an call to an invalid API URL
Chrome console shows this error:

xhr.js:178 GET[ https://]myprivate.gitlab.tld/api/v4/projects/IT%2Fdocs 404 (Not Found)

It seems that maybe it’s trying to call the API with the project name instead of the project ID?
I’m not a Gitlab expert so I don’t wanna get too far out over my skis, but my preliminary research seems to indicate that the API URLs do NOT have the project names in them, they seem to be based on some numeric ID.

We have the same problem using firefox, upgraded from 10.6.4. This instance have been upgraded since early v10 versions, so it might be that th gitlab.rb misses a config setting.
Running gitlab-ee premium, installed and upgraded via the yum repo (omnibus). We do have a license key installed.

Also, we use a separate nginx proxy, but that indicates a 404 thrown by gitlab. The referrer is the edit page (/-/ide/project/projectpath/edit/master/) which does the following request:

We have some logging, but nothing indicating an error:

Started GET “/-/ide/project/projectpath/README” for MYIP at 2018-04-24 08:04:56 +0200
Processing by IdeController#index as HTML
Parameters: {“vueroute”=>“project/projectpath/README”}
Completed 200 OK in 98ms (Views: 80.5ms | ActiveRecord: 3.2ms | Elasticsearch: 0.0ms)
Started GET “/api/v4/projects/PARTIALPROJECTPATH” for MYIP at 2018-04-24 08:04:57 +0200
Started POST “/api/v4/internal/allowed” for at 2018-04-24 08:04:57 +0200
Processing by Gitlab::RequestForgeryProtection::Controller#index as JSON
Completed 200 OK in 1ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms)

The PARTIALPROJECTPATH is the groupnames (group and subgroup) separated by “%2F” that contain the project.

We also have a test installation. For a small project the IDE loaded (after the error). Still, for a (I think) normal sized project, loading doesn’t happen or takes longer than I care to wait.

Same problem here upgrading from 10.6.

Still happening after 10.7.1

Timeout on this request: http://domain/user/project/files/master?format=json

I figured out what’s happening.

That link is hardcoded to the domain name instead of using the domain it’s being accessed through. In my case I’m port forwarding over an SSH tunnel. So I’m hitting localhost:8090 to access gitlab and it’s referencing the domain name which I can’t currently resolve.

In other words, that ajax call should be against : /user/project/files/master?format=json so that it uses whatever domain I’m accessing it through instead of http://domain/user/project/

I bet this works from home.

1 Like

Confirmed this works fine from home when accessed by domain name. At first I was surprised that it fails if I try to use the web ide if I access gitlab by IP instead of domain name. But then I realized it’s probably a CORS issue. I’m in gitlab through 192.168.x.y and it’s trying to do an ajax to http://domain/xyz and I get a 200 response with no body. However, I access that URL directly without issue.

1 Like

10.7.1 update fixed it for us, so I can’t reproduce this anymore

If possible, try to access your gitlab instance by ip and see if it comes back.

Still broken after 10.7.2 update when trying to access by IP.

Failed to load http://domain/user/project/files/master?format=json: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '' is therefore not allowed access.

For anyone that finds this post, there’s an issue open here:

Thanks for your sharing. This was the same issue and fixed by the same way in my situation.