Split the docs up to make them easier to maintain. Fixes #177
--- a/ChangeLog Sun Feb 18 21:26:26 2018 -0600
+++ b/ChangeLog Sun Feb 18 21:47:00 2018 -0600
@@ -19,6 +19,7 @@
* Added a new convey/noop task that does nothing. Fixed #174
* Fixed an issue where relative import paths wouldn't work right if the
convey.yml is in another directory. Fixed #176
+ * Split the docs up to make them easier to maintain. Fixed #177 * Write warning, error, and fatal log messages to stderr. Fixed #156
--- a/REFERENCE.md Sun Feb 18 21:26:26 2018 -0600
+++ b/REFERENCE.md Sun Feb 18 21:47:00 2018 -0600
@@ -1,80 +1,13 @@
-Configuring convey is done via a file named `convey.yml`. This file defines the tasks as well as the plans. This document explains how that file is structured and what options are available.-----
+Configuring convey is done via a file named `convey.yml`. This file defines +the tasks as well as the plans. This document explains how that file is +structured and what options are available. -There are a handful of examples in the [examples/](examples/) directory.-This example shows how to use the convey/bitbucket-upload image to upload files to a Bitbucket repository's downloads section.-## default-plan-alias.yml-A simple plan that aliases the default plan.-A simple plan to show how you can detach a container.-A simple plan to show how you can specify health commands for a detached container.-This example shows how environment substitution works in your config file.-This example shows how you can use meta-plans to group multiple plans together.-This example shows how environment substitution overriding works and uses a -override.yml file as well.-This example shows how to have one file extend another, inheriting all of the plans and tasks that are-not otherwise overwritten by the configuration file.-This example shows how to have one file extend another and specific stages of a plan can be replaced in-This example shows how to expand an environment variable into a list in the context of a extended task.-## environment-from-file.yml-This example shows how to inject variables into the environment from a file in the workspace.-This example shows how you can login and logout of a Docker registry by using environment variables.-This example shows how to use the script attribute of a run task.-This example shows how you can specify an ssh identity to automatically turn on ssh-agent forwarding.-A simple example showing how to use the run attribute of a stage.-This example shows your traditional clone, test, build, deploy, and report for a project.-----
+There are a handful of examples in the [examples/](examples/) directory with a +README.md that describes which each is showing. @@ -93,17 +26,26 @@
-`default-plan` is the name of the plan that should be ran by default. When not set, this defaults to `default`.-----
+`default-plan` is the name of the plan that should be ran by default. When not +set, this defaults to `default`. -You can specify a list of SSH key fingerprints that are required for your run. This is done by using the `ssh-identities` attribute which is a list of SSH key fingerprints with an option checksum prefix. You can also specify `*` to allow any key that's been added to the `ssh-agent`.+You can specify a list of SSH key fingerprints that are required for your run. +This is done by using the `ssh-identities` attribute which is a list of SSH +key fingerprints with an option checksum prefix. You can also specify `*` to +allow any key that's been added to the `ssh-agent`. -`ssh-identities` are also supported in your override file. However, any `ssh-identities` specified in your `convey.yml` will be overridden by the values in the override file; they will not be merged.+`ssh-identities` are also supported in your override file. However, any +`ssh-identities` specified in your `convey.yml` will be overridden by the +values in the override file; they will not be merged. -**NOTE** If running on docker4mac, there is an [issue](https://github.com/docker/for-mac/issues/483) with xhyve (the hypervisor that the Docker daemon runs in) where you can't volume mount the `ssh-agent` socket. You can use this [workaround](https://hub.docker.com/r/uber/ssh-agent-forward/) to expose the `ssh-agent` via an alternative method.+**NOTE** If running on docker4mac, there is an +[issue](https://github.com/docker/for-mac/issues/483) with xhyve (the +hypervisor that the Docker daemon runs in) where you can't volume mount the +`ssh-agent` socket. You can use this +[workaround](https://hub.docker.com/r/uber/ssh-agent-forward/) to expose the +`ssh-agent` via an alternative method. @@ -118,479 +60,37 @@
-----
-The extends option allows you to define a base configuration file. The filepath is relative to the current configuration file.+The extends option allows you to define a base configuration file. The filepath +is relative to the current configuration file. -The current file will inherit the options, tasks, and plans of the base configuration file. If an option is supplied, or a task or plan with the same name is defined in the current file, it replaces the inherited item.----
+The current file will inherit the options, tasks, and plans of the base +configuration file. If an option is supplied, or a task or plan with the same +name is defined in the current file, it replaces the inherited item. -The tasks section defines each task. By defining them separately from the plan the tasks can be reused in multiple plans.-There are many tasks types which can be chosen by the value of the `type` attribute.-----
-The `aws/ecr-login` task will log into AWS Elastic Container Registry. It-depends on the AWS cli package being installed and configured to work.-| Name | Required | Default | Description |-| ------ | -------- | ------- | ----------- |-| region | | | The AWS region to used. |-----
-A clean task will remove files from the host relative and limited to the working directory of convey.-| Name | Required | Default | Description |-| --------- | -------- | ------- | ----------- |-| files | Yes | | A list of filenames relative to the convey working directory to remove. |-----
-An convey/extend task overrides the environment of another task.-| Name | Required | Default | Description |-| ---------------- | -------- | ------- | ----------- |-| task | Yes | | The name of the task to extend |-| environment | | | The override environment |-| expand | | | The envvars which can be expanded into lists on use |-| expand_delimiter | | ; | The string to split mapped values by |-The `expand` and `expand_delimiter` attributes allow an environment variable, which is an unstructured string, to act as if it is an array. This is useful for supplying an "abstract" parent task with several arguments for the same attribute (e.g. tags in a build task). Variables that occur in the environment with a name in expand will be split by the expand delimiter to form a list, where applicable.- image: gliderlabs/alpine:edge- - MESSAGE="Hello, World"-#### Example with Variable Expansion- source: gliderlabs/alpine:edge-----
-A build task will build a docker image.-| Name | Required | Default | Description |-| ---------- | -------- | ------- | ----------- |-| dockerfile | Yes | | The dockerfile to use while building |-| files | | | A list of files that should be made available for the build |-| labels | | | A list of labels to set on the image being built |-| tag | | | The tag to apply to the image |-| tags | | | The list of tags as described above |-| target | | | The name of the target to build in a multi stage dockerfile |-At least one tag must be supplied by either the `tag` or `tags` attribute. If both are-supplied, `tag` is inserted to the front of `tags`.-----
-### docker/environment task-An environment task will read a file with environment variables and make them accessible to your plans.-A file is expected to have lines of the form `variable=value`. Empty lines are ignored. Files are read-from the workspace, so files generated by the plan do not need to be exported in order to be a target-of an environment task. From the other direction, it is necessary to import files on the host if they are-to be read by an environment task.-| Name | Required | Default | Description |-| ---------- | -------- | ------- | ----------- |-| from-file | | | A file that should be read. |-| from-files | | | A list of files that should be read. |-| prefix | | | A prefix to add to each variable read from a file |-At least one file must be supplied by either the `from-file` or `from-files` attributes. If both are supplied,-`from-file` is inserted to the front of `from-files`. If the files being read are a result of environment variable-expansion, the order that the files are read are not guaranteed to be stable (or in the order supplied). Be cautious-of this if the environment files define overlapping variables.- type: docker/environment-----
-An export task copies files from the volume to the host.-| Name | Required | Default | Description |-| ----- | -------- | ------- | ----------- |-| files | Yes | | A single filename or a list of files to copy from the workspace to the host. Files can be specified in one of two forms which can be mixed. The first is `source:destination` and the other is `filename` where filename will be used for both the host and the volume. |- - binary:binary-linux-x86_64-----
-An import task copies files from the host to the volume. It has one required attribute named sources. This is a list of files relative to the directory that convey was run from that will be copied into the volume.-| Name | Required | Default | Description |-| ----- | -------- | ------- | ----------- |-| files | Yes | | A single filename or a list of files to copy from the host to the workspace. Files can be specified in one of two forms which can be mixed. The first is `source:destination` and the other is `filename` where filename will be used for both the host and the volume. |-----
-A login task will run docker login to login to a registry.-| Name | Required | Default | Description |-| -------- | -------- | ------- | ----------- |-| username | Yes | | The username to login with. |-| password | Yes | | The password to login with. |-| server | | | The server to login to. If omitted docker hub is used. |-----
-A logout task will log you out from a Docker registry.+The tasks section defines each task. By defining them separately from the +plan the tasks can be reused in multiple plans. -| Name | Required | Default | Description |-| ------ | -------- | ------- | ----------- |-| server | | | The server to logout from. If omitted docker hub is used. |- server: registry.my.domain:5000-----
-A pull task pulls an image.-| Name | Required | Default | Description |-| ------ | -------- | ------- | ----------- |-| image | | | The name including the tag and registry of the image to pull. |-| images | | | A list of images as described above. |-At least one image must be supplied by either the `image` or `images` attribute. If both are-supplied, `image` is inserted to the front of `images`.- image: gliderlabs/alpine:edge-----
-A push task pushes an image.-| Name | Required | Default | Description |-| ------ | -------- | ------- | ----------- |-| image | | | The name including the tag and registry of the image to push. |-| images | | | A list of images as described above. |-At least one image must be supplied by either the `image` or `images` attribute. If both are-supplied, `image` is inserted to the front of `images`.- - registry.my.domain:5000/newimage:master-latest- - registry.my.domain:5000/newimage:master-deadbeef-----
-A remove task removes an image.-| Name | Required | Default | Description |-| ------ | -------- | ------- | ----------- |-| image | | | The name including the tag and registry of the image to remove. |-| images | | | A list of images as described above. |-| quiet | | false | True if a missing image should not count as a task failure. |-At least one image must be supplied by either the `image` or `images` attribute. If both are-supplied, `image` is inserted to the front of `images`.- - registry.my.domain:5000/newimage:master-latest- - registry.my.domain:5000/newimage:master-deadbeef-----
-A run task runs an image.-| Name | Required | Default | Description |-| ----------- | -------- | ---------- | ----------- |-| command | | | The command to run in the container. This is only necessary if the image does not provide a command by default. |-| detach | | false | Will run the container in the background allowing other tasks to run. The container will be cleaned up on exit. If the image has a HEALTHCHECK specified in the Dockerfile, convey will wait until it is healthy before proceeding. |-| hostname | | | Will set the --network-alias argument in the docker run command. This is generally only useful to connect to service containers. |-| user | | | The user to run as when executing the script or command inside the container. |-| entrypoint | | | The entrypoint to use for the container. This is only necessary if the image does not provide one by default. |-| environment | | | A list of environment variables to set. The should be specified in a `NAME` or `NAME=VALUE` format. If no value is provided, the value of the variable from the host will be provided if it is available. |-| healthcheck | | | See the HealthCheck attributes below. |-| image | Yes | | The image including the registry and tag to run. |-| labels | | | A list of labels to set on the image being built |-| workdir | | | The working directory to use in the container. |-| workspace | | /workspace | The path inside the container to mount the workspace volume. |-#### HealthCheck Attributes-All of these attributes map directory to the `--health` arguments to `docker run`.-| -------- | ----------- |-| command | The command to run as the health check. |-| interval | The interval with which to check the health. |-| retries | The number of attempts before giving up. |-| start-period | How long to wait before starting to check the container's health. |-| timeout | How long to wait for a health check to return before aborting. |+There are many tasks types which can be chosen by the value of the `type` +attribute. See the links below for detailed information on each category of
-A basic example where the image knows everything to do.-A basic example using a standard image to do something else- image: debian:jessie-slim- - wget https://somedomain.tld/file1- - wget https://somedomain.tld/file1.sha256- - sha256sum -c file1.sha256-A more compilicated example waiting for a detached nginx to start- command: wget http://localhost-----
-A tag task will tag an existing image.-| Name | Required | Default | Description |-| ----------- | -------- | ---------- | ----------- |-| source | | | The source image, including registry and tag, to tag. |-| destination | | | The destination tag, including registry and tag, to tag. |- source: registry.my.domain:5000/newimage:latest- destination: registry.my.domain:5000/newimage:development-----
-An apply task will apply kubernetes manifests to the cluster.-| Name | Required | Default | Description |-| ----------| -------- | ---------- | ----------- |-| context | | | The kubernetes context to use. |-| files | Yes | | The list of manifest files to apply. |-| namespace | | | The kubernetes namespace to use. |-| selector | | | The selector to use. |-----
-### kubectl/create Tasks-A create task will create kubernetes manifests on the cluster.-| Name | Required | Default | Description |-| ----------| -------- | ---------- | ----------- |-| context | | | The kubernetes context to use. |-| files | Yes | | The list of manifest files to apply. |-| namespace | | | The kubernetes namespace to use. |-| selector | | | The selector to use. |-----
-### kubectl/delete Tasks-A delete task will delete kubernetes manifests from the cluster.-| Name | Required | Default | Description |-| ----------| -------- | ---------- | ----------- |-| context | | | The kubernetes context to use. |-| files | Yes | | The list of manifest files to apply. |-| namespace | | | The kubernetes namespace to use. |-| selector | | | The selector to use. |-----
+* [convey](intrinsic/README.md) +* [docker](docker/README.md) +* [kubectl](kubectl/README.md) -The environment section defines a list of environment variables to set for the run.+The environment section defines a list of environment variables to set for the -It should be specified in a `NAME` or `NAME=VALUE` format. If no value is provided, the value of the variable from the host will be provided if it is available.+It should be specified in a `NAME` or `NAME=VALUE` format. If no value is +provided, the value of the variable from the host will be provided if it is @@ -600,13 +100,18 @@
-Since there are multiple places where environment variables can be set, they must all be merged together before being passed to a task.+Since there are multiple places where environment variables can be set, they +must all be merged together before being passed to a task. -Environment variables can be set at the `global-base`, `global`, `global-override`, `plan`, `stage`, `task`, and command line levels. The are merged in that order, with the last one taking precedence over the previous.+Environment variables can be set at the `global-base`, `global`, +`global-override`, `plan`, `stage`, `task`, and command line levels. The are +merged in that order, with the last one taking precedence over the previous. -In the following example, when the `env1` task is run, the `FOO` environment variable will be set to `baz`, but when the `env2` task is run, the `FOO` environment variable will be set to bar+In the following example, when the `env1` task is run, the `FOO` environment +variable will be set to `baz`, but when the `env2` task is run, the `FOO` +environment variable will be set to bar @@ -626,7 +131,9 @@
-In the next example, the stage is overriding the global value. So `env1` still has a value of `baz` for the environment variable `FOO`, while `env2` has a value of `qux`.+In the next example, the stage is overriding the global value. So `env1` still +has a value of `baz` for the environment variable `FOO`, while `env2` has a @@ -652,7 +159,8 @@
-The plans sections defines your execution plans which tie everything together by organizing `tasks` into `stages` into the order that they will be executed.+The plans sections defines your execution plans which tie everything together +by organizing `tasks` into `stages` into the order that they will be executed. Each plan is defined by a name in the plans section.
@@ -668,7 +176,8 @@
-Plans themselves are pretty straight forward. They group `stages` with an optional `environment`.+Plans themselves are pretty straight forward. They group `stages` with an @@ -678,15 +187,19 @@
| stages | Yes | A list of `stages` to be run as part of this `plan` in the order that they should be run in. |
| merge | | Whether or not to attempt to merge with a plan defined in the parent config file. |
-If a plan of the same name exists in a parent config file and merge is not set, it will replace the plan in its entirety. If merge is set, then-the stages defined in this plan will overwrite stages of the parent plan with the same name. This behavior also applies to environments. It is an error-to attempt to merge a stage that does not exist in the parent and new stages cannot be added as their order would not be well defined.+If a plan of the same name exists in a parent config file and merge is not set, +it will replace the plan in its entirety. If merge is set, then the stages +defined in this plan will overwrite stages of the parent plan with the same +name. This behavior also applies to environments. It is an error to attempt to +merge a stage that does not exist in the parent and new stages cannot be added +as their order would not be well defined. -Stages group `tasks` together into a logical unit. They can be run sequentially or concurrently.+Stages group `tasks` together into a logical unit. They can be run +sequentially or concurrently. @@ -704,7 +217,8 @@
-Meta plans are used to group plans together and run them in serial. This is also possible via the command line by specifying multiple plans to run.+Meta plans are used to group plans together and run them in serial. This is +also possible via the command line by specifying multiple plans to run. There is currently no support for nesting meta plans.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/aws/README.md Sun Feb 18 21:47:00 2018 -0600
@@ -0,0 +1,20 @@
+The aws package provides tasks for interacting with Amazon Web Services. +The `aws/ecr-login` task will log into AWS Elastic Container Registry. It +depends on the AWS cli package being installed and configured to work. +| Name | Required | Default | Description | +| ------ | -------- | ------- | ----------- | +| region | | | The AWS region to used. | --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/docker/README.md Sun Feb 18 21:47:00 2018 -0600
@@ -0,0 +1,299 @@
+The docker package provides tasks for interacting with docker. +A build task will build a docker image. +| Name | Required | Default | Description | +| ---------- | -------- | ------- | ----------- | +| dockerfile | Yes | | The dockerfile to use while building | +| files | | | A list of files that should be made available for the build | +| labels | | | A list of labels to set on the image being built | +| tag | | | The tag to apply to the image | +| tags | | | The list of tags as described above | +| target | | | The name of the target to build in a multi stage dockerfile | +At least one tag must be supplied by either the `tag` or `tags` attribute. If both are +supplied, `tag` is inserted to the front of `tags`. +## docker/environment Task +An environment task will read a file with environment variables and make them accessible to your plans. +A file is expected to have lines of the form `variable=value`. Empty lines are ignored. Files are read +from the workspace, so files generated by the plan do not need to be exported in order to be a target +of an environment task. From the other direction, it is necessary to import files on the host if they are +to be read by an environment task. +| Name | Required | Default | Description | +| ---------- | -------- | ------- | ----------- | +| from-file | | | A file that should be read. | +| from-files | | | A list of files that should be read. | +| prefix | | | A prefix to add to each variable read from a file | +At least one file must be supplied by either the `from-file` or `from-files` attributes. If both are supplied, +`from-file` is inserted to the front of `from-files`. If the files being read are a result of environment variable +expansion, the order that the files are read are not guaranteed to be stable (or in the order supplied). Be cautious +of this if the environment files define overlapping variables. + type: docker/environment +An export task copies files from the volume to the host. +| Name | Required | Default | Description | +| ----- | -------- | ------- | ----------- | +| files | Yes | | A single filename or a list of files to copy from the workspace to the host. Files can be specified in one of two forms which can be mixed. The first is `source:destination` and the other is `filename` where filename will be used for both the host and the volume. | + - binary:binary-linux-x86_64 +An import task copies files from the host to the volume. It has one required attribute named sources. This is a list of files relative to the directory that convey was run from that will be copied into the volume. +| Name | Required | Default | Description | +| ----- | -------- | ------- | ----------- | +| files | Yes | | A single filename or a list of files to copy from the host to the workspace. Files can be specified in one of two forms which can be mixed. The first is `source:destination` and the other is `filename` where filename will be used for both the host and the volume. | +A login task will run docker login to login to a registry. +| Name | Required | Default | Description | +| -------- | -------- | ------- | ----------- | +| username | Yes | | The username to login with. | +| password | Yes | | The password to login with. | +| server | | | The server to login to. If omitted docker hub is used. | +A logout task will log you out from a Docker registry. +| Name | Required | Default | Description | +| ------ | -------- | ------- | ----------- | +| server | | | The server to logout from. If omitted docker hub is used. | + server: registry.my.domain:5000 +A pull task pulls an image. +| Name | Required | Default | Description | +| ------ | -------- | ------- | ----------- | +| image | | | The name including the tag and registry of the image to pull. | +| images | | | A list of images as described above. | +At least one image must be supplied by either the `image` or `images` attribute. If both are +supplied, `image` is inserted to the front of `images`. + image: gliderlabs/alpine:edge +A push task pushes an image. +| Name | Required | Default | Description | +| ------ | -------- | ------- | ----------- | +| image | | | The name including the tag and registry of the image to push. | +| images | | | A list of images as described above. | +At least one image must be supplied by either the `image` or `images` attribute. If both are +supplied, `image` is inserted to the front of `images`. + - registry.my.domain:5000/newimage:master-latest + - registry.my.domain:5000/newimage:master-deadbeef +A remove task removes an image. +| Name | Required | Default | Description | +| ------ | -------- | ------- | ----------- | +| image | | | The name including the tag and registry of the image to remove. | +| images | | | A list of images as described above. | +| quiet | | false | True if a missing image should not count as a task failure. | +At least one image must be supplied by either the `image` or `images` attribute. If both are +supplied, `image` is inserted to the front of `images`. + - registry.my.domain:5000/newimage:master-latest + - registry.my.domain:5000/newimage:master-deadbeef +A run task runs an image. +| Name | Required | Default | Description | +| ----------- | -------- | ---------- | ----------- | +| command | | | The command to run in the container. This is only necessary if the image does not provide a command by default. | +| detach | | false | Will run the container in the background allowing other tasks to run. The container will be cleaned up on exit. If the image has a HEALTHCHECK specified in the Dockerfile, convey will wait until it is healthy before proceeding. | +| hostname | | | Will set the --network-alias argument in the docker run command. This is generally only useful to connect to service containers. | +| user | | | The user to run as when executing the script or command inside the container. | +| entrypoint | | | The entrypoint to use for the container. This is only necessary if the image does not provide one by default. | +| environment | | | A list of environment variables to set. The should be specified in a `NAME` or `NAME=VALUE` format. If no value is provided, the value of the variable from the host will be provided if it is available. | +| healthcheck | | | See the HealthCheck attributes below. | +| image | Yes | | The image including the registry and tag to run. | +| labels | | | A list of labels to set on the image being built | +| workdir | | | The working directory to use in the container. | +| workspace | | /workspace | The path inside the container to mount the workspace volume. | +### HealthCheck Attributes +All of these attributes map directory to the `--health` arguments to `docker run`. +| -------- | ----------- | +| command | The command to run as the health check. | +| interval | The interval with which to check the health. | +| retries | The number of attempts before giving up. | +| start-period | How long to wait before starting to check the container's health. | +| timeout | How long to wait for a health check to return before aborting. | +A basic example where the image knows everything to do. +A basic example using a standard image to do something else + image: debian:jessie-slim + - wget https://somedomain.tld/file1 + - wget https://somedomain.tld/file1.sha256 + - sha256sum -c file1.sha256 +A more compilicated example waiting for a detached nginx to start + command: wget http://localhost +A tag task will tag an existing image. +| Name | Required | Default | Description | +| ----------- | -------- | ---------- | ----------- | +| source | | | The source image, including registry and tag, to tag. | +| destination | | | The destination tag, including registry and tag, to tag. | + source: registry.my.domain:5000/newimage:latest + destination: registry.my.domain:5000/newimage:development --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/examples/README.md Sun Feb 18 21:47:00 2018 -0600
@@ -0,0 +1,78 @@
+This directory contains quite a few examples of how to use convey. +This example shows how to use the convey/bitbucket-upload image to upload files +to a Bitbucket repository's downloads section. +## default-plan-alias.yml +A simple plan that aliases the default plan. +A simple plan to show how you can detach a container. +A simple plan to show how you can specify health commands for a detached +This example shows how environment substitution works in your config file. +This example shows how you can use meta-plans to group multiple plans together. +This example shows how environment substitution overriding works and uses a +`-override.yml` file as well. +This example shows how to have one file extend another, inheriting all of the +plans and tasks that are not otherwise overwritten by the configuration file. +This example shows how to have one file extend another and specific stages of a +plan can be replaced in the extending file. +This example shows how to expand an environment variable into a list in the +context of a extended task. +## environment-from-file.yml +This example shows how to inject variables into the environment from a file in +This example shows how you can login and logout of a Docker registry by using +This example shows how to use the script attribute of a run task. +This example shows how you can specify an ssh identity to automatically turn on +A simple example showing how to use the run attribute of a stage. +This example shows your traditional clone, test, build, deploy, and report for --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/intrinsic/README.md Sun Feb 18 21:47:00 2018 -0600
@@ -0,0 +1,87 @@
+The intrinsic package provides some intrinsic tasks that convey provides. +A clean task will remove files from the host relative and limited to the working directory of convey. +| Name | Required | Default | Description | +| --------- | -------- | ------- | ----------- | +| files | Yes | | A list of filenames relative to the convey working directory to remove. | +An convey/extend task overrides the environment of another task. +| Name | Required | Default | Description | +| ---------------- | -------- | ------- | ----------- | +| task | Yes | | The name of the task to extend | +| environment | | | The override environment | +| expand | | | The envvars which can be expanded into lists on use | +| expand_delimiter | | ; | The string to split mapped values by | +The `expand` and `expand_delimiter` attributes allow an environment variable, which is an unstructured string, to act as if it is an array. This is useful for supplying an "abstract" parent task with several arguments for the same attribute (e.g. tags in a build task). Variables that occur in the environment with a name in expand will be split by the expand delimiter to form a list, where applicable. + image: gliderlabs/alpine:edge + - MESSAGE="Hello, World" +### Example with Variable Expansion + source: gliderlabs/alpine:edge +A noop task does nothing. It is a "No Operation" task. It's used primarily in +testing, but could be used for stubbing stuff out or whatever. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/kubectl/README.md Sun Feb 18 21:47:00 2018 -0600
@@ -0,0 +1,71 @@
+The kubectl package provides tasks for interacting with kubernetes via kubectl. +It supplies the create, apply, and delete commands. +An apply task will apply kubernetes manifests to the cluster. +| Name | Required | Default | Description | +| ----------| -------- | ---------- | ----------- | +| context | | | The kubernetes context to use. | +| files | Yes | | The list of manifest files to apply. | +| namespace | | | The kubernetes namespace to use. | +| selector | | | The selector to use. | +A create task will create kubernetes manifests on the cluster. +| Name | Required | Default | Description | +| ----------| -------- | ---------- | ----------- | +| context | | | The kubernetes context to use. | +| files | Yes | | The list of manifest files to apply. | +| namespace | | | The kubernetes namespace to use. | +| selector | | | The selector to use. | +A delete task will delete kubernetes manifests from the cluster. +| Name | Required | Default | Description | +| ----------| -------- | ---------- | ----------- | +| context | | | The kubernetes context to use. | +| files | Yes | | The list of manifest files to apply. | +| namespace | | | The kubernetes namespace to use. | +| selector | | | The selector to use. |
