`ship update` should work after `ship init` even if no lifecycle was provided

[laverya]

Expected behavior

ship update should work after ship init even if no lifecycle was provided

Actual behavior

If no lifecycle was provided (leading to the default k8s lifecycle being used) ship update yields the following:

./bin/ship update
Reading https://github.com/replicatedhq/test-charts/tree/master/template-functions ...
Determining application type ...
Detected application type k8s
Looking for ship.yaml ...
ship.yaml not found in upstream, generating default lifecycle for application ...
There was an unexpected error! execute lifecycle step 1: execute kustomize step: write base kustomization: Base directory is empty

There was an error configuring the application. A debug log has been written to ".ship/debug.log", please include it in any support inquiries.

Information

• Ship version: master as of https://github.com/replicatedhq/ship/commit/bd013334eddcd492e1e83322e220a7f2b7e50417
• Command line run: ship init https://github.com/replicatedhq/test-charts/tree/master/template-functions, ship update

Steps to reproduce the behavior

1. run ship init with a source that includes no yaml
2. run ship update and observe failure

[ebramanti]

@marccampbell Talked with @dexhorthy about this and I think this issue needs further discussion.

In this case, the above "chart" only contains Markdown files. We could build something that essentially becomes a "git clone" of raw files compatible with ship init/ship watch but I'm not sure if that's within the scope of this issue.

Currently, when detecting an application, we default to k8s app if it is unable to find a Chart.yaml, but in this case this repo is not a k8s app and will fail on the Kustomize lifecycle step.

[laverya]

My problem wasn't so much that ship update failed as it was that ship init succeeded and then ship update failed. Update should always succeed if init does.