chartmuseum: Deleting a chart that has a version number in its name via the API causes no removal from index

It seems that deleting a chart that has a version number in its name via the API does not delete the entry from the index. The package is deleted from the file system. Seems similar to #22

With a chart named mychart:

curl -X POST -k --data-binary "@mychart-0.1.1.tgz" localhost:8080/api/charts
{"saved":true}

curl localhost:8080/api/charts
{"mychart":[{"name":"mychart","version":"0.1.1","description":"my chart beta","apiVersion":"v1","appVersion":"1.0.0 BETA","urls":["charts/mychart-0.1.1.tgz"],"created":"2019-03-29T16:45:58Z","digest":"be1e1edef408420a3c004b2c88bd9c02ef3f34b6d346fe7a4a264297909da978"}]}

curl -X DELETE localhost:8080/api/charts/mychart/0.1.1
{"deleted":true}

curl localhost:8080/api/charts
{}

With a chart named mychart-1.0

curl -X POST -k --data-binary "@mychart-1.0-0.1.1.tgz" localhost:8080/api/charts
{"saved":true}

curl localhost:8080/api/charts
{"mychart-1.0":[{"name":"mychart-1.0","version":"0.1.1","description":"My Chart","apiVersion":"v1","appVersion":"1.0 BETA","urls":["charts/mychart-1.0-0.1.1.tgz"],"created":"2019-03-29T16:52:01Z","digest":"3a64e207bbc0c69e2027f7795b79c9feb5b64aa18c19e5730f95a09ae0cada57"}]}

curl -X DELETE localhost:8080/api/charts/mychart-1.0/0.1.1
{"deleted":true}

curl localhost:8080/api/charts
{"mychart-1.0":[{"name":"mychart-1.0","version":"0.1.1","description":"My Chart","apiVersion":"v1","appVersion":"1.0 BETA","urls":["charts/mychart-1.0-0.1.1.tgz"],"created":"2019-03-29T16:52:01Z","digest":"3a64e207bbc0c69e2027f7795b79c9feb5b64aa18c19e5730f95a09ae0cada57"}]}

Cheers, Grant

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 5
Comments: 25 (9 by maintainers)

Most upvoted comments

@garnold54 Bug already fixed,please see #268 There are still bugs after the fix，such as version: 0.1.1-58955665. It is inaccurate to find the version by judging whether the first character is a digit.

xiongkun01 on Apr 24, 2020

@kobynet Sorry for my bad reading , but I think I got the point , as #22 mentioned , the semver2 version like 1.0-SNAPSHOT+PR will work as expected. I write some tests to check if 1.0-SNAPSHOT+PR-102 will work out the right version through emptyChartVersionFromPackageFilename function , but it failed with the incorrect version 102 .

Then I look a little deeper into the codebase , and I find that the current solution with only filename but no content Chart.yaml do not actually support the even valid semver2 version like yours 1.0.0-SNAPSHOT+PR-102. It only gets the last numbers series after - , for example , the version like 1.0.0-SNAPSHOT+PR-XXX(replace the number with string characters) will be well parsed.

I will work on a PR these days and thanks for your detail report XD.

(BTW , due to the diff between stored chart and cached chart , stored chart is deleted and cached chart is still there , then the stored chart content is empty , and the cached chart will be never deleted)

scbizu on Aug 6, 2020

@scbizu That is because you put in the version field, the whole chart including it’s name, if you put only version := “1.0-SNAPSHOT+PR-102” it will work fine.

Just for the sake of solving this problem, i’ve also tried with “1.0.0-SNAPSHOT+PR-102” and got the same result, file was deleted, but index wasnt updated after GET requests.

kobynet on Aug 6, 2020

@scbizu This issue happens when there is a index-cache.yaml file created by chartmuseum when i did helm repo update. Then if i delete the versions i mentioned above, the tgz file gets deleted but index-cache.yaml is not recreated/refreshed even if send a GET request or do helm repo update

In the logs it says regenerating but entries are still there.

2020-08-04T07:27:48.867-0400    DEBUG   [5] Incoming request: /api/charts/charts        {"reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Entry found in cache store  {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Fetching chart list from storage    {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Change detected between cache and storage   {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Regenerating index.yaml     {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Removing chart from index   {"repo": "charts", "name": "semvertest-0.1.0-SNAPSHOT", "version": "24", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] index.yaml regenerated      {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Entry saved in cache store  {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}

As you can see parsing is not correct here, "name": "semvertest-0.1.0-SNAPSHOT", "version": "24" version is not 24, it is 0.1.0-SNAPSHOT-24 and name is semvertest

piyush94 on Aug 4, 2020

@scbizu I deleted the chart using API curl -X DELETE http://localhost:8879/api/charts/charts/versiontest/0.1.0-SNAPSHOT-24 I got response code 200, tgz file was also deleted but the index cache was not cleared.

piyush94 on Aug 1, 2020