1

根据 GitLabs API documentation to get a repository tree via restful api call 我应该执行以下操作,此摘录来自可以在此处找到的文档,它说

列出存储库树

获取项目中存储库文件和目录的列表。

GET /projects/:id/repository/tree 参数:

id (必填) - 项目的 ID

path (optional) - 存储库内的路径。用于获取子目录的竞争

ref_name(可选)- 存储库分支或标签的名称,如果没有给出默认分支

但是当我调用上述网络服务时,它会返回

404 您要查找的页面不存在。

我打电话http://myserverurl/api/v3/projects/:id/repository/tree?private_token=myprivatetoken,我得到 404,当然我在这里传递了项目的 id,它是一个整数,如 4、5、6 等。

除了这个之外,所有其他 API 都可以正常工作,这里有什么我遗漏的吗?

这些是我production.log文件中的错误日志

Started GET
"/api/v3/projects/:id/repository/tree?private_token=mytoken&id=4" for
at 2013-06-13 12:48:36 +0530 ActionController::RoutingError (No route
matches [GET] "/api/v3/projects/:id/repository/tree"):
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/debug_exceptions.rb:21:in
`call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/show_exceptions.rb:56:in
`call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:32:in
`call_app'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:16:in
`block in call'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/tagged_logging.rb:22:in
`tagged'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/rack/logger.rb:16:in
`call'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/request_id.rb:22:in
`call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/methodoverride.rb:21:in
`call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/runtime.rb:17:in
`call' vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/lock.rb:15:in
`call'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:136:in
`forward'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:245:in
`fetch'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:185:in
`lookup'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:66:in
`call!'
vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:51:in
`call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/engine.rb:479:in
`call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/application.rb:223:in
`call'
vendor/bundle/ruby/1.9.1/gems/railties-3.2.13/lib/rails/railtie/configurable.rb:30:in
`method_missing'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/builder.rb:134:in
`call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/urlmap.rb:64:in
`block in call'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/urlmap.rb:49:in
`each'
vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/urlmap.rb:49:in
`call'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/configuration.rb:66:in
`call'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/server.rb:364:in
`handle_request'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/server.rb:243:in
`process_client'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/server.rb:142:in
`block in run'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/thread_pool.rb:92:in
`call'
vendor/bundle/ruby/1.9.1/gems/puma-2.0.1/lib/puma/thread_pool.rb:92:in
`block in spawn_thread'
4

2 回答 2

4

Gitlab API 页面“状态代码”部分提到:

404 Not Found

无法访问资源,例如找不到资源的 ID

因此,要么 id 不正确(如果其他 API 调用成功,则不应该如此)。

或者 ' tree' 是不够的,但应该提供一个路径(除非项目树是空的)。

或者有某种权限问题会阻止服务器上的 API 访问该 repo 的内容。

但是,如果任何路径的问题仍然存在,那么值得将该案例添加到GitLab 问题列表中

正如 OP 所提到的,这也表明 API 在 code 中不可用

于 2013-06-13T07:49:54.290 回答
2

这是我的问题,截至 2013 年 6 月 19 日,我没有意识到这个 api 仅在 master 分支上可用,当我将分支从 stable 切换到 master 时,它解决了上述问题,切换了我使用的分支

sudo -u git -H git checkout master

然后我不得不做

须藤捆绑安装

在 master 分支上安装一些额外的 gem,然后我重新启动nginxgitlab使用sudo service nginx restartsudo service gitlab start最后似乎解决了我遇到的所有 api 问题。

于 2013-06-19T10:02:18.683 回答