shipperctl: introduce shipperctl chart render

[hihilla]

Continuing @juliogreff 's work on shipperctl chart render from pr #215

It's useful to know what kind of objects shipper is rendering before
they reach the api server. For debugging issues with YAML
serializing/deserializing, for instance.

For that, you can now run
shipperctl chart render app --filename application.yaml or
shipperctl chart render app --appName foobar or
shipperctl chart render relelase foobar-deadbeef-0

and shipperctl will print a whole bundle of YAML to stdout, with each object separatedby a ---.

$ shipperctl chart render
render Helm Charts for an Application or Release

Usage:
  shipperctl chart render [command]

Available Commands:
  app         render Shipper Charts for an Application
  release     render Shipper Charts for a Release

Flags:
  -h, --help   help for render

Global Flags:
      --kubeconfig string                   the path to the Kubernetes configuration file (default "~/.kube/config")
      --management-cluster-context string   The name of the context to use to communicate with the management cluster. defaults to the current one
  -n, --namespace string                    The namespace where the app lives

Use "shipperctl chart render [command] --help" for more information about a command.

$ shipperctl chart render release -h
render Shipper Charts for a Release

Usage:
  shipperctl chart render release bikerental-7abf46d4-0 [flags]

Flags:
  -h, --help   help for release

Global Flags:
      --kubeconfig string                   the path to the Kubernetes configuration file (default "~/.kube/config")
      --management-cluster-context string   The name of the context to use to communicate with the management cluster. defaults to the current one
  -n, --namespace string                    The namespace where the app lives

$ shipperctl chart render app -h
render Shipper Charts for an Application

Usage:
  shipperctl chart render app [flags]

Flags:
      --appName string               The name of an existing application to render chart for
      --filename applicastion.yaml   An application manifest in the current context to render chart for (e.g. applicastion.yaml)
  -h, --help                         help for app

Global Flags:
      --kubeconfig string                   the path to the Kubernetes configuration file (default "~/.kube/config")
      --management-cluster-context string   The name of the context to use to communicate with the management cluster. defaults to the current one
  -n, --namespace string                    The namespace where the app lives

[nodo]

I am not sure, but I wonder if there is a better way to not have these variables global?

[nodo]

I can see it's consistent with the rest of the commands, but I was a bit confused by this line

[hihilla]

The initial command was getting an appName, pulled it from the cluster and used the chart from it.
I wanted it to be possible to git a yaml of an application that does not exist in the cluster yet.
So with this command you can either give an app name or an application manifest (yaml file name)
The meaning of the variables is in their description in lines 40-41.
Other Go command line code is specifying the flags in a different location so there is no need for global variables. I opted for consistency, but I tend to agree that these global variables are not the best choice. I can start with these commands and have another PR to refactor the rest of shipperctl commands. WDYT?

[nodo]

Thanks for the explanation, I think it makes sense to keep it like that for now. Would you consider this as a potential refactoring for the future?

[hihilla]

Of course! I wanted to do it by now but didn't have the time.
Go's way of doing CLIs is not so gracious, but I have seen some examples of nice ones when I was looking into this (shipperctl decommission shenanigans)

[nodo]

what does applicationP stands for?

[hihilla]

pointer to an application object

[nodo]

I found the name a bit confusing.

Could we do:

application, err = *shipperClient.ShipperV1alpha1().Applications(namespace).Get(appName, metav1.GetOptions{})

or use applicationPointer?

[hihilla]

using * doesn't work because the return type of .Get() is (*Application, error)
So I renamed

[nodo]

Oh of course 🤦