search

emgarten / Sleet

A static nuget feed generator for Azure Storage, AWS S3, and more.
MIT License
362 stars 43 forks source link

Provide alternative S3 baseURI with second set of index files #123

Closed mungojam closed 4 years ago

mungojam commented 4 years ago

I'm open to ideas for solving this one, I think it could be tricky.

The scenario is that I have now got our NuGet packages successfully hosted on S3, accessible via the configured baseURI. However, I now want/need to expose the same package files via a different baseURI. It still points at the same bucket and I can easily point at the root index.json created by sleet. The issue that I didn't foresee is that this then points at the other index files and package files using the original baseURI.

I guess a relative URI just wouldn't work with the nuget client, so I think the only options are:

  1. Create a complete duplicate of my sleet repository, paying for the S3 storage twice.
  2. Create a secondary index, let's say an index2.json that sits alongside every index.json and uses a different baseURI but ultimately leads to the same package files for download, just via a different url.
emgarten commented 4 years ago

I guess a relative URI just wouldn't work with the nuget client

That's correct, the client is designed to use linked data/json-ld which is usually the full URI. Which means we can't fix this on the feed side.

Is one feed a subset of the other and this bucket will get hosted under different urls?

Brainstorming on this, two feeds can be hosted in the same bucket using feedSubPath which puts them into different folders. The flat container format used by nuget client expects a certain url and the index along with that, I'm not sure that could be shared between feeds without seeing all of the packages. Is there any way to symlink inside a bucket or put a redirect for when the client actually tries to retrieve the nupkg?

mungojam commented 4 years ago

Is one feed a subset of the other and this bucket will get hosted under different urls?

Both feeds are identical, we just have an odd setup where some systems would be able to access the bucket via a direct URL while others would need to go via Cloudfront. I was thinking I could generate two different indexes that would use the same underlying bucket objects.

But actually I then looked at the cost of storing the packages twice and realised it was about 5 cents a month, so I've gone for that and happy to close this :)