Closed richerve closed 3 years ago
Hi @richerve,
Thanks a ton for the issue and sorry I haven't commented on it sooner. We're always open to contributions. I think I would lean to add that ability in a non mainline branch/tag. Possible something that would map to drone-helm3:v0.14.4-v2-upgrade or the likes. Mainly because it would add code to maintain which should go away and isn't directly part of helm3 but a plugin. This would allow an upgrade path for folks but not be "fully" supported long term. Does that seem reasonable?
@josmo We decided at the end to have a permanent fork so the code doesn't need to be integrated here if it's not a priority. In any case we squashed the feature in one commit so it should be mergable if you want to cherry-pick it: https://github.com/mongodb-forks/drone-helm3/commit/9d67944ab16fc9211e2647627e1b3aadc5409491
The way is implemented allows to configure the conversion requirements and run convert only when there's no v3 release matching the release name. If a release in v3 is found then even if conversion is enabled, will bypass it and run helm upgrade. So users would need to do the change only once, or defaults on the plugin itself changed to always try the conversion.
Adding a full e2e test, and even unit testing, for this use case is not easy as it involves using helm2, and therefore Tiller, so it's difficult to automate, but there's some test cases for additional functionality added.
We are still adding some features on top of the merged commit, including things like "backing" up the helm2 releases by modifying the Configmap labels after the migration suceeds. But the aforementioned commit works as it is right now.
The problem I'm trying to solve:
Run a migration of a helm v2 Release to a v3 Release before running an "apply" action like install/upgrade.
helm 2to3 exists to do that, but its application is ad-hoc and requires a lot of coordination between the pipeline change and the manual change to convert the releases.
I was in the process of building yet another drone-helm plugin to add this feature, but after looking at the code here, it looks like adding the migration or convert feature to it, won't be as difficult.
I have built a private POC to run the migration as a drone plugin, by using the 2to3 Go package, and adding a little bit of logic around it (explained in the next section).
How I imagine it working:
The plugin will handle the migration automatically if a flag like
migrate_v2
is set to true. Next time a run happens, it will check if a v3 Release is already present and if it's it won't run the migration, but only the action (install/upgrade). If it detects that there's only a v2 Release matching the name, it will migrate. And if it detects a Release using the same name both in v2 and v3, will explicitly fail as that case will require manual intervention.Would you be interested in receiving a PR adding this feature?