From 13b04956a02a0384bfc1ad6b043e901613d1d5b2 Mon Sep 17 00:00:00 2001 From: Meg McRoberts Date: Mon, 22 May 2023 02:08:53 -0700 Subject: [PATCH] docs: content for KeptnTaskDefinition ref and tasks guide (#1392) Signed-off-by: Meg McRoberts Signed-off-by: Meg McRoberts Co-authored-by: odubajDT <93584209+odubajDT@users.noreply.github.com> Co-authored-by: Giovanni Liva Co-authored-by: RealAnna <89971034+RealAnna@users.noreply.github.com> --- docs/content/en/docs/concepts/tasks/_index.md | 177 ---------- .../en/docs/concepts/workloads/_index.md | 44 ++- .../en/docs/implementing/tasks/_index.md | 189 +++++++++++ .../en/docs/tasks/write-tasks/_index.md | 115 ------- .../en/docs/yaml-crd-ref/taskdefinition.md | 307 ++++++++++++++++++ 5 files changed, 524 insertions(+), 308 deletions(-) delete mode 100644 docs/content/en/docs/concepts/tasks/_index.md create mode 100644 docs/content/en/docs/implementing/tasks/_index.md delete mode 100644 docs/content/en/docs/tasks/write-tasks/_index.md diff --git a/docs/content/en/docs/concepts/tasks/_index.md b/docs/content/en/docs/concepts/tasks/_index.md deleted file mode 100644 index b49f8ee3c3..0000000000 --- a/docs/content/en/docs/concepts/tasks/_index.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: Tasks -description: Learn what Keptn Tasks are and how to use them -icon: concepts -layout: quickstart -weight: 10 -hidechildren: true # this flag hides all sub-pages in the sidebar-multicard.html ---- - -### Keptn Task Definition - -A `KeptnTaskDefinition` is a CRD used to define tasks that can be run by the Keptn Lifecycle Toolkit -as part of pre- and post-deployment phases of a deployment. -`KeptnTaskDefinition` resource can be created in the namespace where the application is running, or -in the default KLT namespace, which will be the fallback option for the system to search. -The task definition is a [Deno](https://deno.land/) script -Please, refer to the [function runtime](https://github.com/keptn/lifecycle-toolkit/tree/main/functions-runtime) for more -information about the runtime. -In the future, we also intend to support other runtimes, especially running a container image directly. - -A task definition can be configured in three different ways: - -- inline -- referring to an HTTP script -- referring to another `KeptnTaskDefinition` - -An inline task definition looks like the following: - -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha2 -kind: KeptnTaskDefinition -metadata: - name: deployment-hello -spec: - function: - inline: - code: | - console.log("Deployment Task has been executed"); -``` - -In the code section, it is possible to define a full-fletched Deno script. - -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha2 -kind: KeptnTaskDefinition -metadata: - name: hello-keptn-inline -spec: - function: - inline: - code: | - let text = Deno.env.get("DATA"); - let data; - let name; - data = JSON.parse(text); - - name = data.name - console.log("Hello, " + name + " new"); -``` - -The runtime can also fetch the script on the fly from a remote webserver. -For this, the CRD should look like the -following: - -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha2 -kind: KeptnTaskDefinition -metadata: - name: hello-keptn-http -spec: - function: - httpRef: - url: -``` - -An example is -available [here](https://github.com/keptn-sandbox/lifecycle-toolkit-examples/blob/main/sample-app/version-1/app-pre-deploy.yaml) -. - -Finally, `KeptnTaskDefinition` can build on top of other `KeptnTaskDefinition`s. -This is a common use case where a general function can be re-used in multiple places with different parameters. - -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha2 -kind: KeptnTaskDefinition -metadata: - name: slack-notification-dev -spec: - function: - functionRef: - name: slack-notification - parameters: - map: - textMessage: "This is my configuration" - secureParameters: - secret: slack-token -``` - -## Context - -A context environment variable is available via `Deno.env.get("CONTEXT")`. -It can be used like this: - -```javascript -let context = Deno.env.get("CONTEXT"); - -if (contextdata.objectType == "Application") { - let application_name = contextdata.appName; - let application_version = contextdata.appVersion; -} - -if (contextdata.objectType == "Workload") { - let application_name = contextdata.appName; - let workload_name = contextdata.workloadName; - let workload_version = contextdata.workloadVersion; -} -``` - -## Input Parameters and Secret Handling - -As you might have noticed, Task Definitions also have the possibility to use input parameters. -The Lifecycle Toolkit passes the values defined inside the `map` field as a JSON object. -At the moment, multi-level maps are not supported. -The JSON object can be read through the environment variable `DATA` using `Deno.env.get("DATA");`. -K8s secrets can also be passed to the function using the `secureParameters` field. -Currently only one secret can be passed. -The secret must have a `key` called `SECURE_DATA`. -It can be accessed via the environment variable `Deno.env.get("SECURE_DATA")`. - -For example: - -```yaml -# kubectl create secret generic my-secret --from-literal=SECURE_DATA=foo - -apiVersion: lifecycle.keptn.sh/v1alpha1 -kind: KeptnTaskDefinition -metadata: - name: dummy-task - namespace: "default" -spec: - function: - secureParameters: - secret: my-secret - inline: - code: | - let secret_text = Deno.env.get("SECURE_DATA"); - // secret_text = "foo" -``` - -This methodology supports multiple variables by creating a K8s secret with a JSON string: - -```yaml -# kubectl create secret generic my-secret \ -# --from-literal=SECURE_DATA="{\"foo\": \"bar\", \"foo2\": \"bar2\"}" - -apiVersion: lifecycle.keptn.sh/v1alpha1 -kind: KeptnTaskDefinition -metadata: - name: dummy-task - namespace: "default" -spec: - function: - secureParameters: - secret: my-secret - inline: - code: | - let secret_text = Deno.env.get("SECURE_DATA"); - let secret_text_obj = JSON.parse(secret_text); - // secret_text_obj["foo"] = "bar" - // secret_text_obj["foo2"] = "bar2" -``` - -### Keptn Task - -A Task is responsible for executing the TaskDefinition of a workload. -The execution is done spawning a K8s Job to handle a single Task. -In its state, it keeps track of the current status of the K8s Job created. diff --git a/docs/content/en/docs/concepts/workloads/_index.md b/docs/content/en/docs/concepts/workloads/_index.md index 541be40c1a..f410b9e9bc 100644 --- a/docs/content/en/docs/concepts/workloads/_index.md +++ b/docs/content/en/docs/concepts/workloads/_index.md @@ -7,21 +7,33 @@ weight: 10 hidechildren: true # this flag hides all sub-pages in the sidebar-multicard.html --- -A Workload contains information about which tasks should be performed during the `preDeployment` as well as -the `postDeployment` -phase of a deployment. -In its state it keeps track of the currently active `Workload Instances`, which are responsible -for doing those checks for -a particular instance of a Deployment/StatefulSet/ReplicaSet (e.g. a Deployment of a certain version). +A `KeptnWorkload`resource contains information about +which tasks should be performed during the `preDeployment` +or `postDeployment` phase of a deployment. +In its state, +it keeps track of the currently active `Workload Instances`, +which are responsible for doing those checks +for a particular instance of a Deployment/StatefulSet/ReplicaSet +(e.g. a Deployment of a certain version). -### Keptn Workload Instance +## KeptnWorkload -A Workload Instance is responsible for executing the pre- and post deployment checks of a workload. -In its state, it -keeps track of the current status of all checks, as well as the overall state of -the Pre Deployment phase, which can be used by the scheduler to tell that a pod can be allowed to be placed on a node. -Workload Instances have a reference to the respective Deployment/StatefulSet/ReplicaSet, to check if it has reached the -desired state. -If it detects that the referenced object has reached -its desired state (e.g. all pods of a deployment are up and running), it will be able to tell that -a `PostDeploymentCheck` can be triggered. +A `KeptnWorkload` resource augments a Kubernetes +[Workload](https://kubernetes.io/docs/concepts/workloads/) +with the ability to handle extra phases. +KLT generates the `KeptnWorkload` resource +from metadata information; +it is not necessary to manually create a YAML file that defines it. + +A `KeptnWorkload` instance is responsible for executing +the pre- and post deployment checks of a workload. +In its state, it keeps track of the current status of all checks, +as well as the overall state of the Pre Deployment phase, +which the scheduler can use to determine +whether the deployment should proceed. +`KeptnWorkload` instances refer +to the respective Pod/DeamonSet/StatefulSet/ReplicaSet, +to check whether it has reached the desired state. +If it detects that the referenced object has reached its desired state +(e.g. all pods of a deployment are up and running), +it knows that a `PostDeploymentCheck` can be triggered. diff --git a/docs/content/en/docs/implementing/tasks/_index.md b/docs/content/en/docs/implementing/tasks/_index.md new file mode 100644 index 0000000000..d896143eee --- /dev/null +++ b/docs/content/en/docs/implementing/tasks/_index.md @@ -0,0 +1,189 @@ +--- +title: Working with Keptn tasks +description: Learn how to work with Keptn tasks +weight: 90 +hidechildren: false # this flag hides all sub-pages in the sidebar-multicard.html +--- + +Keptn tasks are defined in a +[KeptnTaskDefinition](../../yaml-crd-ref/taskdefinition.md/) +resource. +A task definition includes a function +that defines the action taken by that task. +It can be configured in one of three different ways: + +- inline +- referring to an HTTP script +- referring to another `KeptnTaskDefinition` +- referring to a + [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) + resource that is populated with the function to execute + +### Context + +A Kubernetes context is a set of access parameters +that contains a Kubernetes cluster, a user, a namespace, +the application name, workload name, and version. +For more information, see +[Configure Access to Multiple Clusters](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). + +You may need to include context information in the `function` code +included in the YAML file that defines a +[KeptnTaskDefinition](../../yaml-crd-ref/taskdefinition.md) +resource. +For an example of how to do this, see the +[keptn-tasks.yaml](https://github.com/keptn-sandbox/klt-on-k3s-with-argocd/blob/main/simplenode-dev/keptn-tasks.yaml) +file. + +A context environment variable is available via `Deno.env.get("CONTEXT")`. +It can be used like this: + +```javascript +let context = Deno.env.get("CONTEXT"); + +if (context.objectType == "Application") { + let application_name = contextdata.appName; + let application_version = contextdata.appVersion; +} + +if (context.objectType == "Workload") { + let application_name = contextdata.appName; + let workload_name = contextdata.workloadName; + let workload_version = contextdata.workloadVersion; +} +``` + +## Parameterized functions + +`KeptnTaskDefinition`s can use input parameters. +Simple parameters are passed as a single map of key values, +while the `secret` parameters refer to a single Kubernetes `secret`. + +Consider the following example: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha2 +kind: KeptnTaskDefinition +metadata: + name: slack-notification-dev +spec: + function: + functionRef: + name: slack-notification + parameters: + map: + textMessage: "This is my configuration" + secureParameters: + secret: slack-token +``` + +Note the following about using parameters with functions: + +- The Lifecycle Toolkit passes the values + defined inside the `map` field as a JSON object. +- Multi-level maps are not currently supported. +- The JSON object can be read through the environment variable `DATA` + using `Deno.env.get("DATA");`. +- Currently only one secret can be passed. + The secret must have a `key` called `SECURE_DATA`. + It can be accessed via the environment variable `Deno.env.get("SECURE_DATA")`. + +## Create secret text + +To create a secret to use in a `KeptnTaskDefinition`, +execute this command: + +```shell +kubectl create secret generic my-secret --from-literal=SECURE_DATA=foo +``` + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: dummy-task + namespace: "default" +spec: + function: + secureParameters: + secret: my-secret + inline: + code: | + let secret_text = Deno.env.get("SECURE_DATA"); + // secret_text = "foo" +``` + +To pass multiple variables +you can create a Kubernetes secret using a JSON string: + +```shell +kubectl create secret generic my-secret \ +--from-literal=SECURE_DATA="{\"foo\": \"bar\", \"foo2\": \"bar2\"}" +``` + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: dummy-task + namespace: "default" +spec: + function: + secureParameters: + secret: my-secret + inline: + code: | + let secret_text = Deno.env.get("SECURE_DATA"); + let secret_text_obj = JSON.parse(secret_text); + // secret_text_obj["foo"] = "bar" + // secret_text_obj["foo2"] = "bar2" +``` + +## Pass secrets to a function + +In the previous example, you see that +Kubernetes +[secrets](https://kubernetes.io/docs/concepts/configuration/secret/) +can be passed to the function +using the `secureParameters` field. + +Here, the `secret` value is the name of the Kubernetes secret, +which contains a field with the key `SECURE_DATA`. +The value of that field is then available to the function's runtime +via an environment variable called `SECURE_DATA`. + +For example, if you have a task function that should make use of secret data, +you must first ensure that the secret containing the `SECURE_DATA` key exists +For example: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: deno-demo-secret + namespace: default +type: Opaque +data: + SECURE_DATA: YmFyCg== # base64 encoded string, e.g. 'bar' +``` + +Then, you can make use of that secret as follows: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: deployment-hello + namespace: "default" +spec: + function: + secureParameters: + secret: deno-demo-secret + inline: + code: | + console.log("Deployment Hello Task has been executed"); + + let foo = Deno.env.get('SECURE_DATA'); + console.log(foo); + Deno.exit(0); +``` diff --git a/docs/content/en/docs/tasks/write-tasks/_index.md b/docs/content/en/docs/tasks/write-tasks/_index.md deleted file mode 100644 index 88bed96f31..0000000000 --- a/docs/content/en/docs/tasks/write-tasks/_index.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Write Keptn Tasks -description: Learn how to use the Keptn Lifecycle Toolkit and explore basic features. -icon: concepts -layout: quickstart -weight: 20 -hidechildren: true # this flag hides all sub-pages in the sidebar-multicard.html ---- - -## Keptn Task Definition - -A `KeptnTaskDefinition` is a CRD used to define tasks that can be run by the Keptn Lifecycle Toolkit -as part of pre- and post-deployment phases of a deployment. -The task definition is a [Deno](https://deno.land/) script. -In the future, we also intend to support other runtimes, especially running a container image directly. - -A task definition can be configured in three different ways: - -- inline -- referring to an HTTP script -- referring to another `KeptnTaskDefinition` - -An inline task definition looks like the following: - -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha2 -kind: KeptnTaskDefinition -metadata: - name: deployment-hello -spec: - function: - inline: - code: | - console.log("Deployment Task has been executed"); -``` - -In the code section, it is possible to define a full-fletched Deno script. - -The runtime can also fetch the script on the fly from a remote webserver. -For this, the CRD should look like the -following: - -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha2 -kind: KeptnTaskDefinition -metadata: - name: hello-keptn-http -spec: - function: - httpRef: - url: -``` - -Finally, `KeptnTaskDefinition` can build on top of other `KeptnTaskDefinition`s. -This is a common use case where a general function can be re-used in multiple places with different parameters. - -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha2 -kind: KeptnTaskDefinition -metadata: - name: slack-notification-dev -spec: - function: - functionRef: - name: slack-notification - parameters: - map: - textMessage: "This is my configuration" - secureParameters: - secret: slack-token -``` - -As you might have noticed, Task Definitions also have the possibility to use input parameters. -The Lifecycle Toolkit passes the values defined inside the `map` field as a JSON object. -At the moment, multi-level maps are not supported. -The JSON object can be read through the environment variable `DATA` using `Deno.env.get("DATA");`. -Kubernetes secrets can also be passed to the function using the `secureParameters` field. - -Here, the `secret` value is the name of the K8s secret containing a field with the key `SECURE_DATA`. -The value of that field will then be available to the functions runtime via an environment variable called `SECURE_DATA`. - -For example, if you have a task function that should make use of secret data, you must first ensure that the secret -containing the `SECURE_DATA` key exists, as e.g.: - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: deno-demo-secret - namespace: default -type: Opaque -data: - SECURE_DATA: YmFyCg== # base64 encoded string, e.g. 'bar' -``` - -Then, you can make use of that secret as follows: - -```yaml -apiVersion: lifecycle.keptn.sh/v1alpha3 -kind: KeptnTaskDefinition -metadata: - name: deployment-hello - namespace: "default" -spec: - function: - secureParameters: - secret: deno-demo-secret - inline: - code: | - console.log("Deployment Hello Task has been executed"); - - let foo = Deno.env.get('SECURE_DATA'); - console.log(foo); - Deno.exit(0); -``` diff --git a/docs/content/en/docs/yaml-crd-ref/taskdefinition.md b/docs/content/en/docs/yaml-crd-ref/taskdefinition.md index 877444e902..b4e50388b9 100644 --- a/docs/content/en/docs/yaml-crd-ref/taskdefinition.md +++ b/docs/content/en/docs/yaml-crd-ref/taskdefinition.md @@ -3,3 +3,310 @@ title: KeptnTaskDefinition description: Define tasks that can be run pre- or post-deployment weight: 89 --- + + +A `KeptnTaskDefinition` defines tasks +that are run by the Keptn Lifecycle Toolkit +as part of the pre- and post-deployment phases of a +[KeptnApp](./app.md) or +[KeptnWorkload](../concepts/workloads/). + +## Yaml Synopsis + +```yaml +apiVersion: lifecycle.keptn.sh/v?alpha? +kind: KeptnTaskDefinition +metadata: + name: +spec: + function: + inline | httpRef | functionRef | ConfigMapRef + parameters: + map: + textMessage: "This is my configuration" + secureParameters: + secret: slack-token +``` + +## Fields + +* **apiVersion** -- API version being used. +` +* **kind** -- Resource type. + Must be set to `KeptnTaskDefinition` + +* **metadata** + * **name** -- Unique name of this task. + Names must comply with the + [Kubernetes Object Names and IDs](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names) + specification. + +* **spec** + * **function** -- Code to be executed, + expressed as a [Deno](https://deno.land/) script. + Refer to [function runtime](https://github.com/keptn/lifecycle-toolkit/tree/main/functions-runtime) + for more information about the runtime. + + The `function` can be defined as one of the following: + + * **inline** - Include the actual executable code to execute. + This can be written as a full-fledged Deno script + that is included in this file. + For example: + + ```yaml + function: + inline: + code: | + console.log("Deployment Task has been executed"); + ``` + + * **httpRef** - Specify a Deno script to be executed at runtime + from the remote webserver that is specified. + For example: + + ```yaml + name: hello-keptn-http + spec: + function: + httpRef: + url: "https://www.example.com/yourscript.js" + ``` + + * **functionRef** -- Execute one or more `KeptnTaskDefinition` resources + that have been defined. + Populate this field with the value(s) of the `name` field + for the `KeptnTaskDefinition`(s) to be called. + This is commonly used to call a general function + that is used in multiple places, possibly with different parameters. + An example is: + + ```yaml + spec: + function: + functionRef: + name: slack-notification + ``` + + This can also be used to group a set of tasks + into a single `KeptnTaskDefinition`, + such as defining a `KeptnTaskDefinition` for testing. + In this case, it calls other, existing `KeptnTaskDefinition`s + for each type of test to be run, + specifying each by the value of the `name` field. + * **ConfigMapRef** - Specify the name of a + [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) + resource that contains the function to be executed. + + * **parameters** - An optional field to supply input parameters to a function. + The Lifecycle Toolkit passes the values defined inside the `map` field + as a JSON object. + For example: + + ```yaml + spec: + parameters: + map: + textMessage: "This is my configuration" + ``` + + See + [Parameterized functions](../implementing/tasks/#parameterized-functions) + for more information. + + * **secureParameters** -- An optional field used to pass a Kubernetes secret. + The `secret` value is the Kubernetes secret name + that is mounted into the runtime and made available to functions + using the `SECURE_DATA` environment variable. + For example: + + ```yaml + secureParameters: + secret: slack-token + ``` + + Note that, currently, only one secret can be passed. + + See [Create secret text](../implementing/tasks/#create-secret-text) + for details. + +## Usage + +A Task executes the TaskDefinition of a +[KeptnApp](app.md) or [KeptnWorkload]. +The execution is done by spawning a Kubernetes +[Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) +to handle a single Task. +In its state, it tracks the current status of this Kubernetes Job. + +The `function` is coded in JavaScript +and executed in +[Deno](https://deno.com/runtime), +which is a lightweight runtime environment +that executes in your namespace. +Note that Deno has tighter restrictions +for permissions and importing data +so a script that works properly elsewhere +may not function out of the box when run in Deno. + +A task can be executed either pre-deployment or post-deployment +as specified in the `Deployment` resource; +see +[Pre- and post-deployment tasks](../implementing/integrate/#pre--and-post-deployment-checks) +for details. +Note that the annotation identifies the task by `name`. +This means that you can modify the `function` code in the resource definition +and the revised code is picked up without additional changes. + +## Examples + +### Example 1: inline script + +This example defines a full-fledged Deno script +within the `KeptnTaskDefinition` YAML file: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: hello-keptn-inline +spec: + function: + inline: + code: | + let text = Deno.env.get("DATA"); + let data; + let name; + data = JSON.parse(text); + + name = data.name + console.log("Hello, " + name + " new"); +``` + +### Example 2: httpRef script + +This example fetches the Deno script from a remote webserver at runtime: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: hello-keptn-http +spec: + function: + httpRef: + url: "https://www.example.com/yourscript.js" +``` + +For another example, see the +[sample-app](https://github.com/keptn-sandbox/lifecycle-toolkit-examples/blob/main/sample-app/version-1/app-pre-deploy.yaml). + +See the +[sample-app/version-1](https://github.com/keptn-sandbox/lifecycle-toolkit-examples/blob/main/sample-app/version-1/app-pre-deploy.yaml) +PodtatoHead example for a more complete example. + +### Example 3: functionRef + +This example calls another defined task, +illustrating how one `KeptnTaskDefinition` can build +on top of other `KeptnTaskDefinition`s. +In this case, it calls `slack-notification-dev`, +passing `parameters` and `secureParameters` to that other task: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: slack-notification-dev +spec: + function: + functionRef: + name: slack-notification + parameters: + map: + textMessage: "This is my configuration" + secureParameters: + secret: slack-token +``` + +### Example 4: ConfigMapRef + +This example references a `ConfigMap` by the name of `dev-configmap` +that contains the code for the function to be executed. + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha3 +kind: KeptnTaskDefinition +metadata: + name: keptntaskdefinition-sample +spec: + function: + configMapRef: + name: dev-configmap +``` + +### Example 5: ConfigMap + +This example illustrates the use of both a `ConfigMapRef` and a `ConfigMap`: + +```yaml +apiVersion: lifecycle.keptn.sh/v1alpha2 +kind: KeptnTaskDefinition +metadata: + name: scheduled-deployment +spec: + function: + configMapRef: + name: scheduled-deployment-cm-1 +--- +apiVersion: v1 +kind: ConfigMap +metadata: + name: scheduled-deployment-1 +data: + code: | + let text = Deno.env.get("DATA"); + let data; + if (text != "") { + data = JSON.parse(text); + } + let targetDate = new Date(data.targetDate) + let dateTime = new Date(); + if(targetDate < dateTime) { + console.log("Date has passed - ok"); + Deno.exit(0); + } else { + console.log("It's too early - failing"); + Deno.exit(1); + } + console.log(targetDate); +``` + +### More examples + +See the [operator/config/samples](https://github.com/keptn/lifecycle-toolkit/tree/main/operator/config/samples/function_execution) +directory for more example `KeptnTaskDefinition` YAML files. + +## Files + +API Reference: + +* [KeptnTaskDefinition](../crd-ref/lifecycle/v1alpha3/_index.md#keptntaskdefinition) +* [KeptnTaskDefinitionList](../crd-ref/lifecycle/v1alpha3/_index.md#keptntaskdefinitionlist) +* [KeptnTaskDefinitionSpec](../crd-ref/lifecycle/v1alpha3/_index.md#keptntaskdefinitionspec) +* [FunctionReference](../crd-ref/lifecycle/v1alpha3/_index.md#functionreference) +* [FunctionSpec](../crd-ref/lifecycle/v1alpha3/_index.md#functionspec) +* [FunctionStatus](../crd-ref/lifecycle/v1alpha3/_index.md#functionstatus) +* [HttpReference](../crd-ref/lifecycle/v1alpha3/_index.md#httpreference) +* [Inline](../crd-ref/lifecycle/v1alpha3/_index.md#inline) + +## Differences between versions + +The `KeptnTaskDefinition` is the same for +all `v1alpha?` library versions. + +## See also + +* [Working with tasks](../implementing/tasks) +* [Pre- and post-deployment tasks](../implementing/integrate/#pre--and-post-deployment-checks) +* [Orchestrate deployment checks](../getting-started/orchestrate)