It looks like a change in cache.go to get the actual chart objects from storage when fetching the chart list forgot to join the repository path prefix to the object path like it should. The offending commit is ff22877 and the lines in question are below:
|
for _, object := range allObjects { |
|
if object.HasExtension(cm_repo.ChartPackageFileExtension) { |
|
// Since ListObject cannot fetch the content from file list |
|
object, err = server.StorageBackend.GetObject(object.Path) |
|
if err != nil { |
|
return nil, fmt.Errorf("backend storage: chart not found: %q", err) |
|
} |
|
filteredObjects = append(filteredObjects, object) |
|
} |
|
} |
L207 should be doing pathutil.Join(repo, object.Path) like similar calls elsewhere in this and other files:
|
func (server *MultiTenantServer) getObjectChartVersion(repo string, object cm_storage.Object, load bool) (*helm_repo.ChartVersion, error) { |
|
op := object.Path |
|
if load { |
|
var err error |
|
objectPath := pathutil.Join(repo, op) |
|
object, err = server.StorageBackend.GetObject(objectPath) |
I'd guess that this works fine with other storage providers and since they only seem to remove a prefix if it is present, they would have handled the missing prefix happily. But I'm commenting based on a short period of reading this code so it's definitely something worth looking into and smoke testing against more storage backends at least.
It looks like a change in
cache.goto get the actual chart objects from storage when fetching the chart list forgot to join the repository path prefix to the object path like it should. The offending commit is ff22877 and the lines in question are below:chartmuseum/pkg/chartmuseum/server/multitenant/cache.go
Lines 204 to 213 in ff22877
L207 should be doing
pathutil.Join(repo, object.Path)like similar calls elsewhere in this and other files:chartmuseum/pkg/chartmuseum/server/multitenant/cache.go
Lines 312 to 317 in ff22877
I'd guess that this works fine with other storage providers and since they only seem to remove a prefix if it is present, they would have handled the missing prefix happily. But I'm commenting based on a short period of reading this code so it's definitely something worth looking into and smoke testing against more storage backends at least.