Allow relative urls in location_path for downloader #1799
Conversation
|
@DarthHater Thanks for this and for cookbook support in Nexus! Imma play with these specs a little. |
|
|
||
| it "that are absolute and uses the given absolute URI" do | ||
| allow(remote_cookbook).to receive(:location_path) { "http://some.bucket.somewhere.example.com:8081/repository/chef-proxy/api/v1" } | ||
| expect(CommunityREST).to receive(:new).with("http://some.bucket.somewhere.example.com:8081/repository/chef-proxy/api/v1", { ssl: {} }) { rest } |
There was a problem hiding this comment.
I know I wrote this bit, but after looking at Downloader.try_download and CommunityREST.download, the some.bucket.somewhere.example.com I added here doesn't make sense. 🤦♂️
Downloader.try_download under test here is still poking at a particular Supermarket API endpoint. It's not until CommunityREST.download goes to retrieve the actual archive that a URL might be something other than the Supermarket endpoint (e.g. an S3 bucket for the actual cookbook artifact).
So, uh, some.bucket.somewhere.example.com can go back to being localhost to make sense in context. 😬
DarthHater
force-pushed
the
RelativeUrlsInLocationPath
branch
from
80977c3
to
00756e3
Compare
From original PR: Hi there! I'm working on a chef plugin for Nexus Repository, and I ran into some fun! When using berkshelf to install, it initially hits /universe to get the chef dependency graph. This graph includes a bunch of absolute URLs, which makes for fun times when proxying a repository. I wrote a utility that sets all those URLs to relative, which would in theory work with a tool, and it did for knife (I don't think it uses universe), but berkshelf was not so happy. The reason we prefer relative URLs for Nexus Repo is because once we get into building a group type functionality (grouping multiple repositories under one accessible URL), it makes life a lot easier. What I did in this PR was check to see if the location_path was set to relative, and if it is, I take the source.uri_string and append the two together, as the source.uri_string SHOULD be the location for Nexus Repo, etc... if your berksfile is configured correctly. I am probably opening a can of worms with this PR, so feel free to let me know if this is a poorly thought out change. A few tests appear to be failing but I believe they are unrelated to this change. Signed-off-by: Jeffry Hesse <jeffryxtron@gmail.com>
DarthHater
force-pushed
the
RelativeUrlsInLocationPath
branch
from
00756e3
to
632ab24
Compare
|
I endorse these force pushes.
|
|
|
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Hi there!
I'm working on a chef plugin for Nexus Repository, and I ran into some fun!
When using berkshelf to install, it initially hits /universe to get the chef dependency graph. This graph includes a bunch of absolute URLs, which makes for fun times when proxying a repository. I wrote a utility that sets all those URLs to relative, which would in theory work with a tool, and it did for knife (I don't think it uses universe), but berkshelf was not so happy. The reason we prefer relative URLs for Nexus Repo is because once we get into building a group type functionality (grouping multiple repositories under one accessible URL), it makes life a lot easier.
What I did in this PR was check to see if the location_path was set to relative, and if it is, I take the source.uri_string and append the two together, as the source.uri_string SHOULD be the location for Nexus Repo, etc... if your berksfile is configured correctly.
I am probably opening a can of worms with this PR, so feel free to let me know if this is a poorly thought out change.
A few tests appear to be failing but I believe they are unrelated to this change.