Refactor where templated manifest files are written to

[tonglil]

Idea

Currently they are output into the /tmp directory, which means they are discarded when this plugin completes.

One useful feature is to preserve the output and upload the applied manifests to S3/GCS/storage so they can be viewed/used later.

The output directory MUST be changed to somewhere in the workspace.Path (NOT workspace.Root) in order to comply with those plugins to access and upload them (see https://github.com/drone-plugins/drone-google-cloudstorage/issues/10).

Implications

The Secrets manifest (.kube.sec.yml) is no longer "ephemeral" in this plugin's container, and persists until the end of the entire Drone build.

This risk should be acceptable since the secret is already in Drone as environment variables ($$SECRET).

However, this would be a concern for users of this plugin who are uploading their entire workspace.Path to S3, as the output directory is now in the workspace.Path!

Alternatives

1. Write the output to somewhere in the workspace.Root instead of workspace.Path, and fork existing plugins to support accessing files in workspace.Root.

2. Alert users of this change, and ask them to update their S3/GCS configs to ignore: this output directory.

Next steps

1. Determine what to do.
2. This is related to Refactor method of applying K8s resource files #27.

[msuterski]

What's the use case for use them later? How would they be used later? Somehow uploaded manually to the drone? Or added to the repo?

Could view them later be an option behind a debug flag? I'd assume someone would want to look at them for debugging purposes?

[tonglil]

Being able to store them in S3/GCS would enable:

• Storing/analyzing past deployments configurations
• Enabling rollback by kubectl apply -f
• Replicating the environment locally (in minikube) or in another cluster

The issue is that the only manifests people have access to are templates, and this would allow people to upload complete manifests to some storage service.