Adding dependencies fails for alias-based repositories

[joeyb]

Expected behavior

Recent snapshots of Istio 1.1 contain dependency repository references that are aliases (e.g. https://github.com/istio/istio/blob/1.1.0-snapshot.6/install/kubernetes/helm/istio/requirements.yaml#L64). If those aliases aren't already set (via previous helm repo add calls), then ship should either prompt for the URLs for those aliases or fail with a useful error message (the latter is likely much easier, and would be good enough).

Actual behavior

Regardless of whether or not you have a repo added with the given alias, ship fails on the 3rd step of ship init with the following error message:

execute render step: execute plan: execute templating: add requirements deps for https://github.com/istio/istio/tree/1.1.0-snapshot.6/install/kubernetes/helm/istio: add helm repo @istio.io: helm repo add failed, output "": Could not find protocol handler for:

It looks like the code in ship that handles those dependencies does not understand aliases: https://github.com/replicatedhq/ship/blob/57fe3a3ccddb5d6109400db950018ace52da25f4/pkg/lifecycle/render/helm/dependency.go#L33

That block needs an additional clause that handles repositories starting with @ or alias: and treats them as alias references.

Information

• Ship version: 0.33.0
• Docker version: 18.09.1
• Command line run: ship init https://github.com/istio/istio/tree/1.1.0-snapshot.6/install/kubernetes/helm/istio

Steps to reproduce the behavior

1. ship init https://github.com/istio/istio/tree/1.1.0-snapshot.6/install/kubernetes/helm/istio
2. Leave the default values and hit next, should fail on the 3rd step with the error message described above.

[dexhorthy]

Want to give a quick update on this issue with the state of discussion and some workarounds. It looks like there are two things at play here:

• missing alias parsing in the if repoURL.Scheme == ... cases (I believe @joeyb may have a fix for this)
• Ship creates its own temporary HELM_HOME, which means that even if we properly parse the alias, we wont get the user's repo aliases that they've previously configured.

Proposed solutions

Right now the proposed solutions to the helm home mismatch are

• Use the user's configured HELM_HOME, either automatically or via a flag (I believe we may have hit an issue with this in the past but I don't recall what it was)
• Parse HELM_HOME and try to merge the user's ~/.helm stuff into the temporary helm home created by Ship
• Add a flag to ship init that would allow a user to set helm aliases at runtime (we'd probably need to store these in state.json for updates)
• Add a step in the default UI lifecycle for configuring aliases found in the chart's requirements.yaml

Workaround for app/chart maintainers

For chart maintainers, a workaround here would be to remove @ aliases from requirements.yaml, and instead use direct links to repo in question.

For example, instead of

repository: "@stable"

you can use

repository: https://kubernetes-charts.storage.googleapis.com/

[laverya]

One thing we could do (besides the 4 solutions you've proposed) is add a textbox for a list of aliases to the current helm template settings step - hide it in an advanced settings toggle

I don't think it needs an independent step, since we don't render the helm chart until after you choose the settings anyways

[dexhorthy]

Having an alias section on the values page is probably an appropriate alternative to 4, perhaps a 4b. The reason to make a discrete step would be if the UI on that values page gets too busy.

[laverya]

I think we already have an 'advanced' dropdown to allow changing the helm namespace - it could go in there, which wouldn't really increase the business of that page. (it would greatly hurt discoverability, though)