Unpin helmfile and helm in argocd-helmfile-plugin

[kb-yamashita]

What

Unpin helmfile and helm in argocd-helmfile-plugin/variant.mod.

   helmfile:
-    version: "1.1.5"
+    version: "> 0.1"
   helm:
-    version: "3.21.3"
+    version: "~ 3"

Why

The hourly dependency update job has been failing continuously since helmfile v1.8.0 was released:

resolving dependency "helmfile": no semver matching "1.1.5" found in [1.1.6 ... 1.8.0]

mod fetches the GitHub Releases list without a per_page parameter, so it only ever sees the first 30 entries. The exact pin 1.1.5 fell off that first page when v1.8.0 was published, leaving nothing for the constraint to match. The update workflow runs every directory through xargs, so this single failure takes the whole job down and the notification fires every hour.

This is the only directory in the repository using an exact pin. The other 22 all use ranges, which is why none of them are affected — a range always matches something within the latest 30 releases. The failure mode requires an exact pin.

The pin was introduced as a temporary measure while a staged helmfile v1 migration was in progress. That migration is complete, so the pin is no longer needed.

Choice of constraints

helmfile: "> 0.1" restores what this directory used before the pin, and matches every other directory in this repository.

helm: "~ 3" keeps helm on the 3.x line so that moving to helm v4 stays a separate, deliberate decision. helm v4 changes CLI flags and output, and reworks the plugin mechanism — this image installs helm-diff, helm-secrets and helm-git as plugins, so that move deserves its own verification.

Note

"< 4" would not work here. With Masterminds/semver v1.5.0 (which mod v0.25.3 uses), a constraint that omits the minor and patch is treated as "major <= 4" rather than "< 4.0.0", so < 4 and >= 3, < 4 both still match 4.3.0. ~ 3 is the reliable way to express the upper bound.

Resolved versions against the current release listings:

constraint	resolves to
helmfile: "> 0.1"	v1.8.0
helm: "~ 3"	v3.22.0

Pre-releases are excluded automatically — a constraint without a pre-release never matches one — so validVersionPattern is not needed here.

Effect of merging

This PR only touches variant.mod, which ci:diff excludes, so merging it builds and pushes nothing by itself. The next scheduled mod up will open a follow-up PR that regenerates Dockerfile and goss/goss.yaml, and that is what produces a new image.

Consumers of this image pin explicit tags rather than following latest, so nothing is upgraded implicitly by this change.

Checklist

• The diff does not contain hardcoded secrets, API keys, tokens, or passwords
• This PR's title, description, commit messages, and comments have never contained internal-only ticket keys
• The same applies to internal domains, internal URLs, secret/service names, or other internal-only info
• I have actually checked the edit history of this PR/issue/commits for the above
• Attached files/screenshots do not show internal domains, internal URLs, hostnames, or other internal-only info