Multiple Gitlab.client objects appear to interfere with each other about gitlab HOT 11 CLOSED

It shouldn't.

Request URI: https://gitlab1/api/v3/projects

Error shows that endpoint didn't change, is that true? What is the value of g1.private_token?

from gitlab.

I did some testing and, for me, the endpoint displayed in the error is always the last one that was used during instantiation. I can't reproduce the error output shown above.

If a relative path is passed, HTTParty prepends the base_uri (we set it here: https://github.com/NARKOZ/gitlab/blob/master/lib/gitlab/request.rb#L84). If we pass the full URI when calling get, post etc. - we get the desired behavior.

from gitlab.

I pushed up the code I was playing with that fixes this issue (see linked commit above) - provided we can get confirmation the problem lies with the endpoint. Once confirmed and if there's no issue with how I approached the fix, I would be happy to merge it into master.

from gitlab.

I retested and it does look like the endpoint, though the g1.endpoint variable doesn't change. I used variables this time to avoid any anonymization errors:

[43] pry(main)> g1 = Gitlab.client(:endpoint => host1, :private_token => token1)
=> #<Gitlab::Client:0x007f365e3ac2a8
 @endpoint="https://<gitlab1>/api/v3/",
 @private_token="<token1>",
 @sudo=nil,
 @user_agent="Gitlab Ruby Gem 3.2.0">
[44] pry(main)> g1.projects.length
=> 20
[45] pry(main)> g2 = Gitlab.client(:endpoint => "host", :private_token => "bar")
=> #<Gitlab::Client:0x007f365e454e30 @endpoint="host", @private_token="bar", @sudo=nil, @user_agent="Gitlab Ruby Gem 3.2.0">
[46] pry(main)> g1.projects.length
SocketError: getaddrinfo: Name or service not known
from /usr/local/lib/ruby/2.1.0/net/http.rb:879:in `initialize'
[47] pry(main)> g1.endpoint == host1
=> true
[48] pry(main)> g1.private_token == token1
=> true

from gitlab.

@CCTJNII Thanks for retesting. g1.endpoint shouldn't change - the problem lies elsewhere.

@NARKOZ - how do you feel about the linked/proposed fix?

from gitlab.

Added a spec in 1ec8b38 and it's passing.

I don't think it requires any fixes.

from gitlab.

@NARKOZ I still think it's an issue. Here's (hopefully) a better illustration of the problem:

irb(main):003:0> g1 = Gitlab.client(endpoint: 'http://foo', private_token: 'foo')
=> #<Gitlab::Client:0x00000002cddb68 @endpoint="http://foo", @private_token="foo", @user_agent="Gitlab Ruby Gem 3.2.0", @sudo=nil, @httparty=nil>
irb(main):004:0> Gitlab::Client.base_uri
=> "http://foo"
irb(main):005:0> g2 = Gitlab.client(endpoint: 'http://bar', private_token: 'bar')
=> #<Gitlab::Client:0x00000002bddb28 @endpoint="http://bar", @private_token="bar", @user_agent="Gitlab Ruby Gem 3.2.0", @sudo=nil, @httparty=nil>
irb(main):006:0> Gitlab::Client.base_uri
=> "http://bar"

If you don't pass an absolute URL to HTTParty::get (for example), the base_uri is automatically prefixed to the relative path. The endpoint is passed to HTTParty::base_uri during instantiation by Gitlab::Request#set_request_defaults.

There may be a better way to handle this than the fix I proposed.

from gitlab.

Yes, base_uri is the issue, not endpoint directly. The real question in my mind is whether anyone will ever be communicating with 2 distinct GitLab instances. It may be a minor issue.

At any rate, I found a report of this in HTTParty and the maintainer is not interested in making base_uri an instance variable. They suggest prefixing the endpoint in each 'get', etc method.

from gitlab.

@asedge can you push a fix?

from gitlab.

Done.

from gitlab.

Thanks.

Nihad Abbasov

On Thu, Dec 18, 2014 at 6:38 PM, Sean Edge [email protected] wrote:

Done.

—
Reply to this email directly or view it on GitHub
#94 (comment).

from gitlab.