prerelease versions cannot be used from lock file by default

[ostlerc]

I am trying to set a pre-release version in my lock file. it looks something like this.

version: v0.115.0
dependencies:
- name: auth
  repository: https://myrepo
  version: 0.5.2-release20200527.2+49d32d0
...

my yaml looks something like this

releases:
- chart: myrepo/auth
  name: auth
  namespace: ns

running helmfile diff I immediately get

in ./helmfile.yaml: no resolved dependency found for "auth"

Note that this command works
helm upgrade auth myrepo/auth --version '0.5.2-release20200527.2+49d32d0'

if I change my yaml to look like

releases:
- chart: myrepo/auth
  name: auth
  version:  0.5.2-release20200527.2+49d32d0
  namespace: ns

then the helmfile command works. I would expect to be able to specify my unstable chart version in the lock file and for it to be found. it only seems to be found while explicitly set in my helmfile.yaml.

EDIT: to any seeing this, you must set the version constraint in the helmfile.yaml for your release to be able to install prerelease versions, just editing manually lock files won't do it.

[mumoshu]

@ostlerc Hey. Unfortunately I think I don't understand the issue fully. Would you mind clarifying a bit more?

First, why you need --skip-deps? I thought that removing it would just grab the prerelease from https://myrepo which will make the no resolved dependency error disappear?

[ostlerc]

very sorry for the confusion. the --skip-deps is of no consequence it doesn't have anything to do with the problem.
I tried to be very clear in the description. the issue is still present without that flag. i updated the description to reflect this.

[ostlerc]

I see the root issue. If we do not specify a version in the helmfile yaml for a release we seem to use the constraint '*' by default. * in the masterminds semver library essentially means >=0.0.0 and by that definition my version does not match.
My next question is, is this what we want as a default? Can we ignore constraints if the lock file has a specific version we want already?

this is the code i'm talking about in chart_dependency.go

func (d *ResolvedDependencies) Get(chart, versionConstraint string) (string, error) {
	if versionConstraint == "" {
		versionConstraint = "*"
	}

	deps, exists := d.deps[chart]
	if exists {
		for _, dep := range deps {
			constraint, err := semver.NewConstraint(versionConstraint)
			if err != nil {
				return "", err
			}
			version, err := semver.NewVersion(dep.Version)
			if err != nil {
				return "", err
			}

			if constraint.Check(version) {
				return dep.Version, nil
			}
		}
	}
	return "", fmt.Errorf("no resolved dependency found for \"%s\"", chart)
}

We are trying to use the lock file as the version to be used. It's extremely confusing when doing a diff with a lock file for helmfile to try to find versions at all for me, it especially doesn't make sense to me that we try to apply constraints that restrict pre-release without explicitly stating in the yaml that is what we want.

[mumoshu]

@ostlerc Would u mind clarifying a bit more - How did you set 0.5.2-release20200527.2+49d32d0 in the lock file? Did you manually edit it?

[mumoshu]

I thought that the point of using * as the default constraint was to avoid locking to a prerelease version unless explicitly stated so in your helmfile.yaml. You usually want helmfile to lock on non-pre release versions by default, right?

[mumoshu]

In other words, I was wondering if this was your intention:

releases:
- chart: myrepo/auth
  name: auth
  namespace: ns
  version: ">=0.0.0-0"

[ostlerc]

very interesting. yes we are in the habit of manually editing the lockfile for specific versions. that constraint you gave me is very useful, I think I will use that.
until tonight looking at the code I didn't realize that version in the yaml was a constraint, and I didn't know in order to allow pre-release we needed this. this is very helpful and I think it's a good work around for us at this time.

another side conversation would be if we are not meant to use the lock file to specify the versions we want, are you expecting everyone to use constraints and update their dependencies every helmfile command? I noticed it seems to really want to do that without the flags. I can see that it is useful for keeping things up to date, but we are trying to use helmfile as a way to guarantee an exact state of our cluster. essentially just a list of charts with versions we want and some values files magic sprinkled around.

[mumoshu]

are you expecting everyone to use constraints and update their dependencies every helmfile command?

If one wants to do that, yes. But anyway, it's intended to be used in CI to let helmfile fetch the latest version numbers that satisfy the constraint and update the lock file automatically. Lock files are for helmfile to edit, not human. People would review helmfile.lock updated by helmfile though, rather than people manually editing it.

That being said, in your case, I was expecting that you would just write the below as you do seem to know the exact version number you want:

releases:
- chart: myrepo/auth
  name: auth
  version:  0.5.2-release20200527.2+49d32d0
  namespace: ns

I think it doesn't matter if version is internally a constraint or not. I was expecting you would specify it in helmfile.yaml, not in the lock file.

Can I ask why you've been updating the lock file manually?

[ostlerc]

we have a template of all our applications and would require passing that in for each one. currently it's just a list of chart names. the lock file was the easiest place to see all versions in one location and editing the lock file gave the results that we want (setting versions). We could use constraints, but I think the general consensus is we are making ourselves choose versions to deploy for production and don't need to worry about them changing without human intervention.

I'm happy to talk more about it if you'd like. Just let me know if you have any further questions on the subject. Perhaps a takeaway from this is that it was not obvious to me how this should be used. also the ability to use the constraints in the yaml is a nice feature perhaps if we had understood from the beginning our workflow would be different right now.