-
-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple Gitlab.client objects appear to interfere with each other #94
Comments
It shouldn't.
Error shows that endpoint didn't change, is that true? What is the value of |
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 |
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. |
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 |
Added a spec in 1ec8b38 and it's passing. I don't think it requires any fixes. |
@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 There may be a better way to handle this than the fix I proposed. |
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. |
@asedge can you push a fix? |
Done. |
Thanks. Nihad Abbasov On Thu, Dec 18, 2014 at 6:38 PM, Sean Edge notifications@github.com wrote:
|
The config data appears to not be unique across Gitlab.client objects:
I would expect that instantiating a new Gitlab.client object not change existing class behavior.
The text was updated successfully, but these errors were encountered: