left-pad helm chart filenames with 0s to fix sorting

[laverya]

Description

Fixes # (issue)

Currently, helm chart apply order is determined by sorting the helm chart manifest filenames. The order is included as the first element in the filename, resulting in names like 1_helm_extension_chartname.yaml.

Manifests are fetched here, which uses filepath.Glob, which calls sort on the results.

Unfortunately, this breaks at 10 - 10_helm_extension_anothername.yaml is alphabetically before 1_helm_extension_chartname.yaml.

This PR adds a fmt directive to left-pad these integers to 9 digits, which allows sorting to work properly - see https://go.dev/play/p/THZg3TD6eHI.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Manual test
• Auto test added

Checklist:

• My code follows the style guidelines of this project
• My commit messages are signed-off
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[laverya]

I'm trying to work out how to add an auto test - is there a way to specify a config to be applied in CI? If so, I can just have two charts order 1 and 10 where 1 provides resources used by 10 😄

[twz123]

Thanks for looking into this. Can you provide an example of what you'd like to fix, so that we can cover this in an integration test? K0s does offer the order field on Helm extensions, but this may not work quite as expected. The file names control the order in which chart resources are applied to the cluster, but the actual installation happens when those resources are reconciled. Not sure if the order is guaranteed in any way on that end.

Previous related PRs:

• Issue2966/helm extensions improvals #2974
• Fix helm race condition #3633

[laverya]

Well, we've seen pretty consistent behavior where charts are initially applied in the order of their sorted filenames - and we recently merged a change to increase all 'order' values by 100 to allow orders 10-90 to work properly. (we also have a 'is this pod older than this other pod' check in CI now, to ensure that things are actually being applied in the right order) I'm not sure if the reconciliation order is guaranteed either, but I don't think we've seen it run outside of that order upon initial install yet!

[laverya]

Let me get an example spec in a moment.

[laverya]

(we had initially discovered this due to a demo helm chart with incorrect configuration that was applied before the ones we actually required, and never completed, blocking installation of the other charts until the timeout, and so I need to create a better example)

[github-actions]

The PR is marked as stale since no activity has been recorded in 30 days

[github-actions]

The PR is marked as stale since no activity has been recorded in 30 days