-
Notifications
You must be signed in to change notification settings - Fork 82
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
Cleanup previous chart #1197
Comments
Another option is to keep the current implementation as it is and include "rm -rf " as a step before executing the tar command. This will ensure that when the tar command is executed a new folder with the chart name will get created. |
devdattakulkarni
changed the title
Untar a service's chart in destination folders with service name
Cleanup previous chart
Dec 18, 2023
devdattakulkarni
added a commit
that referenced
this issue
Dec 18, 2023
devdattakulkarni
added a commit
that referenced
this issue
Dec 18, 2023
devdattakulkarni
added a commit
that referenced
this issue
Dec 18, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently in helmer and kubeconfiggenerator, a Service's chart is untarred with a command like so:
Inside untarChart.untar cmd:tar -xvzf wordpress-chart-0.0.1.tgz
This creates the chart in a folder named "wordpress-chart".
The problem is, that if there is already a folder with that name, then the above operation will not overwrite that folder.
Instead, the contents of the earlier folder will remain in-tact and the newly untarred folder contents will be added to it.
This is problematic.
A better approach will be to untar each service's chart in a folder with that service name.
The change would look like this:
mkdir <service-name> && tar -xvzf wordpress-chart-0.0.1.tgz -C <service-name>
The subsequent steps in which we are using the chart-name in helm install will need to change to instead use the service-name used above in the helm install command.
The text was updated successfully, but these errors were encountered: