Madz Niza

For variables we can use gotemplate and toml to provide the values. we can add `value_file` or any better name for that? as param in deploy ``` yaml - name:...

for approach 1 these are the sample files: manifest.yml ``` --- kind: Service apiVersion: v1 metadata: name: {{.name}} namespace: {{default "kontinuous" .namespace}} spec: selector: app: {{.name}} type: ci-cd ports: -...

we can add `globalvars` in definition.yml to cater global variables and `localvars` for stage specific variables. In case a `localvars` key has the same key in `globalvars`, we'll use that...

initial list of Kontinuous variables to be exposed to the user ``` "KONTINUOUS_PIPELINE_ID": Generated UUID for pipeline "KONTINUOUS_BUILD_ID": Current build number "KONTINUOUS_STAGE_ID": Curren stage number "KONTINUOUS_BRANCH": Build Branch "KONTINUOUS_NAMESPACE": Namespace...

it's use in the kontinuous agent to `git clone` source.

the list is just partial. we can cherry-pick on what would be useful to the user.

Fixes #53 Added support for templated deployment manifest file/s Added support for templated pipeline yaml Added support for single file / directory for deployment resources - `deploy_file` for single file...

yes.

kontinuous expose works on non-existent service. If service exists and will have a change on service type. kubectl apply -f on service will fail. https://github.com/kubernetes/kubernetes/issues/23651