diff --git a/deploy/artifact-secret.yaml b/deploy/artifact-secret.yaml index 0d3cb32a02bc..c2d9cc1f38df 100644 --- a/deploy/artifact-secret.yaml +++ b/deploy/artifact-secret.yaml @@ -5,5 +5,5 @@ kind: Secret metadata: name: default-minio-credentials data: - accessKey: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK - secretKey: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo= + accessKey: QUtJQUlPU0ZPRE5ON0VYQU1QTEU= + secretKey: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQ== diff --git a/examples/arguments-artifacts.yaml b/examples/arguments-artifacts.yaml index 2a9d1605e589..ee2bf5327edd 100644 --- a/examples/arguments-artifacts.yaml +++ b/examples/arguments-artifacts.yaml @@ -1,3 +1,9 @@ +# Like parameters, artifacts can be "passed" to a template as well. +# In this example, the 'kubectl-input-artifact' template requires +# that an an artifact named 'kubectl' is supplied as an input, +# which it will place in /usr/local/bin/kubectl. This keeps the +# template more composable/flexible, than if the location was +# hard-wired inside the template. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/artifact-passing.yaml b/examples/artifact-passing.yaml index 8428bcb9b1ad..dd301b9ac116 100644 --- a/examples/artifact-passing.yaml +++ b/examples/artifact-passing.yaml @@ -1,3 +1,5 @@ +# This example demonstrates the ability to pass artifacts +# from one step to the next. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/coinflip-recursive.yaml b/examples/coinflip-recursive.yaml index c3d52895d665..82e85d3bb6cb 100644 --- a/examples/coinflip-recursive.yaml +++ b/examples/coinflip-recursive.yaml @@ -1,3 +1,8 @@ +# coinflip-recursive is a variation of the coinflip example. +# This is an example of a dynamic workflow which extends +# indefinitely until it acheives a desired result. In this +# example, the 'flip-coin' step is recursively repeated until +# the result of the step is "heads". apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/coinflip.yaml b/examples/coinflip.yaml index 2f3c143f8bd0..f90c3d75a794 100644 --- a/examples/coinflip.yaml +++ b/examples/coinflip.yaml @@ -1,3 +1,8 @@ +# The coinflip example combines the use of a script result, +# along with conditionals, to take a dynamic path in the +# workflow. In this example, depending on the result of the +# first step, 'flip-coin', the template will either run the +# 'heads' step or the 'tails' step. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/conditionals.yaml b/examples/conditionals.yaml index c1a056dcf9ec..02bd44a9538c 100644 --- a/examples/conditionals.yaml +++ b/examples/conditionals.yaml @@ -1,3 +1,12 @@ +# Conditionals provide a way to affect the control flow of a +# workflow at runtime, depending on parameters. In this example +# the 'print-hello' template may or may not be executed depending +# on the input parameter, 'should-print'. When submitted with: +# argo submit examples/conditionals.yaml +# the step will be skipped since 'should-print' will evaluate false. +# When submitted with: +# argo submit examples/conditionals.yaml -p should-print=true +# the step will be executed since 'should-print' will evaluate true. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/fun_with_gifs.yaml b/examples/fun-with-gifs.yaml similarity index 97% rename from examples/fun_with_gifs.yaml rename to examples/fun-with-gifs.yaml index 57d188ab4363..3e44d4629cf9 100644 --- a/examples/fun_with_gifs.yaml +++ b/examples/fun-with-gifs.yaml @@ -1,6 +1,6 @@ # Example of GIF processing using ImageMagick and Gifsicle. # -# This commit adds an example of processing gifs using ImageMagick and gifsicle. +# This is an example of workflow processing gifs using ImageMagick and gifsicle. # The workflow creates a PVC that is used for locally storing the downloaded # images and then running 'convert' and 'gifsicle' on these images. # diff --git a/examples/input-artifact-git.yaml b/examples/input-artifact-git.yaml index abdd9ecde23f..29e484fc63fb 100644 --- a/examples/input-artifact-git.yaml +++ b/examples/input-artifact-git.yaml @@ -1,3 +1,6 @@ +# This example demonstrates the use of a git repo as a hard-wired +# input artifact. The argo repo is cloned to its target destination +# at '/src' for the main container to consume. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/input-artifact-http.yaml b/examples/input-artifact-http.yaml index bec28e8e0a25..51b798e58170 100644 --- a/examples/input-artifact-http.yaml +++ b/examples/input-artifact-http.yaml @@ -1,4 +1,4 @@ -# Example of using a hard-wired artifact location +# Example of using a hard-wired artifact location from a HTTP URL. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/input-artifact-s3.yaml b/examples/input-artifact-s3.yaml index 4fd0862e6255..13e6d0677a1b 100644 --- a/examples/input-artifact-s3.yaml +++ b/examples/input-artifact-s3.yaml @@ -1,4 +1,4 @@ -# This example demonstrates the loading a hard-wired input artifact from an S3 compliant +# This example demonstrates the loading of a hard-wired input artifact from an S3 compliant # store. This can be AWS S3, Google Cloud Storage (GCS) with interoperability enabled, # or a self-hosted minio service. S3 guards access to buckets using an access key and # secret key, which will be stored as regular Kubernetes secrets, and referenced in the diff --git a/examples/node-selector.yaml b/examples/node-selector.yaml index 020f1219aa2d..5c77d70c7b1a 100644 --- a/examples/node-selector.yaml +++ b/examples/node-selector.yaml @@ -1,6 +1,6 @@ # This example demonstrates a workflow with a step using node selectors. -# In this case, it requires that the print-arch template step, runs on a -# node with architecture 'amd64', which can be overriden via argo CLI. +# In this case, it requires that the 'print-arch' template, run on a +# node with architecture 'amd64'. This can be overriden via argo CLI, # e.g. argo submit node-selector.yaml -p arch=somethingelse # Node selectors can also be set at the workflow level, meaning all pods # of the workflow will be scheduled using the selector. diff --git a/examples/output-artifact-s3.yaml b/examples/output-artifact-s3.yaml new file mode 100644 index 000000000000..6bc68325b94c --- /dev/null +++ b/examples/output-artifact-s3.yaml @@ -0,0 +1,43 @@ +# This is an example of a workflow producing an S3 output artifact +# which is saved to a hard-wired location. This is useful for workflows +# which want to publish results to a well known or predetermiend +# location. +apiVersion: argoproj.io/v1alpha1 +kind: Workflow +metadata: + generateName: output-artifact-s3- +spec: + entrypoint: whalesay + templates: + - name: whalesay + container: + image: docker/whalesay:latest + command: [sh, -c] + args: ["cowsay hello world | tee /tmp/hello_world.txt"] + outputs: + artifacts: + - name: message + path: /tmp/hello_world.txt + s3: + # Use the corresponding endpoint depending on your S3 provider: + # AWS: s3.amazonaws.com + # GCS: storage.googleapis.com + # Minio: my-minio-endpoint.default:9000 + endpoint: s3.amazonaws.com + bucket: my-bucket + # NOTE that all output artifacts are automatically tarred and + # gzipped before saving. So as a best practice, .tgz or .tar.gz + # should be incorporated into the key name so the resulting file + # has an accurate file extension. + key: path/in/bucket/hello_world.tgz + # accessKeySecret and secretKeySecret are secret selectors. + # It references the k8s secret named 'my-s3-credentials'. + # This secret is expected to have have the keys 'accessKey' + # and 'secretKey', containing the base64 encoded credentials + # to the bucket. + accessKeySecret: + name: my-s3-credentials + key: accessKey + secretKeySecret: + name: my-s3-credentials + key: secretKey diff --git a/examples/output-artifact.yaml b/examples/output-artifact.yaml deleted file mode 100644 index b910a323d506..000000000000 --- a/examples/output-artifact.yaml +++ /dev/null @@ -1,16 +0,0 @@ -apiVersion: argoproj.io/v1alpha1 -kind: Workflow -metadata: - generateName: output-artifact- -spec: - entrypoint: whalesay - templates: - - name: whalesay - container: - image: docker/whalesay:latest - command: [sh, -c] - args: ["cowsay hello world | tee /tmp/hello_world.txt"] - outputs: - artifacts: - - name: message - path: /tmp/hello_world.txt diff --git a/examples/output-parameter.yaml b/examples/output-parameter.yaml index 79e4e09a44d6..c2ab13dd96fb 100644 --- a/examples/output-parameter.yaml +++ b/examples/output-parameter.yaml @@ -1,18 +1,48 @@ +# Output parameters provide a way to use the contents of a file, +# as a parameter value in a workflow. In that regard, they are +# similar in concept to script templates, with the difference being +# that the ouput parameter values are obtained via file contents +# instead of stdout (as with script templates). Secondly, there can +# be multiple 'output.parameters.xxx' in a single template, versus +# a single 'output.result' from a script template. +# +# In this example, the 'whalesay' template produces an output +# parameter named 'hello-param', taken from the file contents of +# /tmp/hello_world.txt. This parameter is passed to a subsequent +# step as an input parameter to the template, 'print-message'. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: - generateName: output-parameters- + generateName: output-parameter- spec: - entrypoint: whalesay + entrypoint: output-parameter templates: + - name: output-parameter + steps: + - - name: generate-parameter + template: whalesay + - - name: consume-parameter + template: print-message + arguments: + parameters: + - name: message + value: "{{steps.generate-parameter.outputs.parameters.hello-param}}" + - name: whalesay container: image: docker/whalesay:latest command: [sh, -c] args: ["echo -n hello world > /tmp/hello_world.txt"] outputs: - # Output as parameters, this enables user to store certain file content - # into a parameter. In the other steps, user can reference this parameter parameters: - - name: message + - name: hello-param path: /tmp/hello_world.txt + + - name: print-message + inputs: + parameters: + - name: message + container: + image: docker/whalesay:latest + command: [cowsay] + args: ["{{inputs.parameters.message}}"] diff --git a/examples/parameter-passing.yaml b/examples/parameter-passing.yaml deleted file mode 100644 index 36ace39323c0..000000000000 --- a/examples/parameter-passing.yaml +++ /dev/null @@ -1,36 +0,0 @@ -apiVersion: argoproj.io/v1alpha1 -kind: Workflow -metadata: - generateName: parameter-passing- -spec: - entrypoint: parameter-example - templates: - - name: parameter-example - steps: - - - name: generate-parameter - template: whalesay - - - name: consume-parameter - template: print-message - arguments: - parameters: - - name: message - value: "{{steps.generate-parameter.outputs.parameters.hello-param}}" - - - name: whalesay - container: - image: docker/whalesay:latest - command: [sh, -c] - args: ["echo -n hello world > /tmp/hello_world.txt"] - outputs: - parameters: - - name: hello-param - path: /tmp/hello_world.txt - - - name: print-message - inputs: - parameters: - - name: message - container: - image: docker/whalesay:latest - command: [cowsay] - args: ["{{inputs.parameters.message}}"] diff --git a/examples/scripts-bash.yaml b/examples/scripts-bash.yaml index f039f90d6ab3..2c9cb08706c2 100644 --- a/examples/scripts-bash.yaml +++ b/examples/scripts-bash.yaml @@ -1,3 +1,10 @@ +# script templates provide a way to run arbitary snippets of code +# in any language, to produce a output "result" via the standard out +# of the template. Results can then be referenced using the variable, +# {{steps..outputs.result}}, and used as parameter to other +# templates, and in 'when', and 'withParam' clauses. +# This example demonstrates the use of a bash shell script to +# generate a random number which is printed in the next step. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/scripts-javascript.yaml b/examples/scripts-javascript.yaml index 713e2f311501..d19d392c3347 100644 --- a/examples/scripts-javascript.yaml +++ b/examples/scripts-javascript.yaml @@ -1,3 +1,10 @@ +# script templates provide a way to run arbitary snippets of code +# in any language, to produce a output "result" via the standard out +# of the template. Results can then be referenced using the variable, +# {{steps..outputs.result}}, and used as parameter to other +# templates, and in 'when', and 'withParam' clauses. +# This example demonstrates the use of a javascript script to +# generate a random number which is printed in the next step. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/scripts-python.yaml b/examples/scripts-python.yaml index 8e032604bcd7..bcff4a28be8e 100644 --- a/examples/scripts-python.yaml +++ b/examples/scripts-python.yaml @@ -1,3 +1,10 @@ +# script templates provide a way to run arbitary snippets of code +# in any language, to produce a output "result" via the standard out +# of the template. Results can then be referenced using the variable, +# {{steps..outputs.result}}, and used as parameter to other +# templates, and in 'when', and 'withParam' clauses. +# This example demonstrates the use of a python script to +# generate a random number which is printed in the next step. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/sidecar-dind.yaml b/examples/sidecar-dind.yaml index b8f0053063ad..467bb101dade 100644 --- a/examples/sidecar-dind.yaml +++ b/examples/sidecar-dind.yaml @@ -1,3 +1,7 @@ +# sidecar-dind (dind is an acronym for docker-in-docker) demonstrates +# the ability to run docker commands (e.g. `docker run`, `docker build`) +# from within a container, by running the docker daemon as a sidecar to +# the main container. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: diff --git a/examples/testvolume.yaml b/examples/testvolume.yaml index e435d2152701..0d7e64bf5998 100644 --- a/examples/testvolume.yaml +++ b/examples/testvolume.yaml @@ -1,7 +1,7 @@ -# This PVC manifest is to be used in conjunction with -# the volumes-existing.yaml example. Create this PVC -# using `kubectl create -f testvolume.yaml`, then submit -# the volumes-existing.yaml example. +# This PVC manifest is to be used in conjunction with the +# volumes-existing.yaml example. Create this PVC using +# `kubectl create -f testvolume.yaml`, then submit this +# volumes-existing.yaml example. kind: PersistentVolumeClaim apiVersion: v1 metadata: diff --git a/examples/volumes-pvc.yaml b/examples/volumes-pvc.yaml index 058691a9be23..46c548195581 100644 --- a/examples/volumes-pvc.yaml +++ b/examples/volumes-pvc.yaml @@ -1,7 +1,7 @@ # This example demonstrates the ability for a workflow to create a # temporary, ephemeral volume used by the workflow, and delete it # when the workflow completes. It uses the same volumeClaimTemplates -# syntax with statefulsets. +# syntax as statefulsets. apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: