This document lists each Pivotal Platform Automation task,
and provides information about their intentions, inputs, and outputs.
The tasks are presented, in their entirety,
as they are found in the product.
The docker image can be used to invoke the commands in each task locally.
Use --help for more information. To learn more see the running-commands-locally section.
apply-changes
Triggers an install on the Ops Manager described by the auth file.
Info
Ops Manager Verifier failures when applying changes will prevent deployment.
In cases where these verifiers are incorrectly failing for known reasons,
they should be disabled using om.
The --ignore-warnings option for om apply-changes
allows users to ignore all warnings from ignorable verifiers.
This option is not available in Platform Automation.
In an automation context, disabling only the particular verifiers
where failure is well-understood allows other verifiers
to continue to provide important feedback.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
assign-multi-stemcell assigns multiple stemcells to a provided product.
This feature is only available in OpsMan 2.6+.
For more information on how to utilize this workflow,
check out the Stemcell Handling topic.
```yaml tab="Task"
This feature is only available in OpsMan 2.6+.
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the configuration file for assign-multi-stemcell command
# - Example config:
# ---
# product: cf
# stemcell:
# - ubuntu-trusty:1234.6
# - ubuntu-xenial:latest
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
CONFIG_FILE: config.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the assign-multi-stemcell-config input
### assign-stemcell
`assign-stemcell` assigns a stemcell to a provided product.
For more information on how to utilize
this workflow, check out the [Stemcell Handling][stemcell-handling] topic.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the configuration file for assign-stemcell command
# - Can consume the output of `download-product` task directly
# - Example config:
# ---
# product: cf
# stemcell: 3468.86
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `env` input
CONFIG_FILE: config.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `assign-stemcell-config` input
run:
path: platform-automation-tasks/tasks/assign-stemcell.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" assign-stemcell \
--config config/"$CONFIG_FILE"
Returns a table of the current state of your Ops Manager
and lists whether each product is changed or unchanged and the errands for that product.
By default, ALLOW_PENDING_CHANGES: false will force the task to fail.
This is useful to keep manual changes from being accidentally applied
when automating the configure-product/apply-changes of other products.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
ALLOW_PENDING_CHANGES: false
# - Optional
# - If false, will fail if there are pending changes in OpsMan
### collect-telemetry
Collects foundation information
using the [Pivotal Telemetry][telemetry-docs] tool.
This task requires the `telemetry-collector-binary` as an input.
The binary is available on [Pivotal Network][telemetry];
you will need to define a `resource` to supply the binary.
This task requires a [config file][telemetry-config].
After using this task,
the [send-telemetry][send-telemetry]
may be used to send telemetry data to Pivotal.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: telemetry-collector-binary
- name: env # contains the env file with target OpsMan Information
- name: config # contains the product configuration file
# - Example config:
# ---
# env_type: sandbox | development | qa | pre-production | production
# with_credhub_info: false
# cf_api_url: cf.example.com
# usage_service_url: service.example.com
# usage_service_client_id: client
# usage_service_client_secret: secret
# usage_service_insecure_skip_tls_verify: false
outputs:
- name: collected-telemetry-data
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `env` input
CONFIG_FILE: config.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `config` input
run:
path: platform-automation-tasks/tasks/collect-telemetry.sh
```bash tab="Implementation"
set -eux
cat config/"$CONFIG_FILE" env/"$ENV_FILE" > combined-config.yml
sed 's/---//g' combined-config.yml > clean-config.yml
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the auth configuration
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
AUTH_CONFIG_FILE: auth.yml
# - Required
# - Filepath of the authorization config YAML
# - The path is relative to root of the config input
VARS_FILES:
# - Optional
# - Filepath to the Ops Manager vars yaml file
# - The path is relative to root of the task build,
# so vars and secrets can be used.
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" configure-authentication \
--config config/"${AUTH_CONFIG_FILE}" \
${vars_files_args[@]}
For details on the config file expected in the `config` input,
please see [Generating an Auth File][generating-an-auth-file].
### configure-director
Configures the BOSH Director with settings from a config file.
See [staged-director-config](#staged-director-config),
which can extract a config file.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: config # contains the director configuration file
- name: env # contains the env file with target OpsMan Information
- name: vars # variable files to be made available
optional: true
- name: secrets
# secret files to be made available
# separate from vars, so they can be store securely
optional: true
- name: ops-files # operations files to custom configure the product
optional: true
params:
VARS_FILES:
# - Optional
# - Filepath to the Ops Manager vars yaml file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
OPS_FILES:
# - Optional
# - Filepath to the Ops Manager operations yaml files
# - The path is relative to root of the task build
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `env` input
DIRECTOR_CONFIG_FILE: director.yml
# - Required
# - Filepath to the director configuration yaml file
# - The path is relative to the root of the `config` input
run:
path: platform-automation-tasks/tasks/configure-director.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
ops_files_args=("")
for of in ${OPS_FILES}
do
ops_files_args+=("--ops-file ${of}")
done
${vars_files_args[@] needs to be globbed to pass through properly
${ops_files_args[@] needs to be globbed to pass through properly
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the auth configuration
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
AUTH_CONFIG_FILE: auth.yml
# - Required
# - Filepath of the authorization config YAML
# - The path is relative to root of the config input
VARS_FILES:
# - Optional
# - Filepath to the Ops Manager vars yaml file
# - The path is relative to root of the task build,
# so vars and secrets can be used.
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" configure-ldap-authentication \
--config config/"${AUTH_CONFIG_FILE}" \
${vars_files_args[@]}
For more details on using LDAP,
please refer to the [Ops Manager documentation][config-ldap].
For details on the config file expected in the `config` input,
please see [Generating an Auth File][generating-an-auth-file].
### configure-product
Configures an individual, staged product with settings from a config file.
Not to be confused with Ops Manager's
built-in [import][bbr-import],
which reads all deployed products and configurations from a single opaque file,
intended for import as part of backup/restore and upgrade lifecycle processes.
See [staged-config](#staged-config),
which can extract a config file,
and [upload-and-stage-product](#upload-and-stage-product),
which can stage a product that's been uploaded.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: config # contains the product configuration file
- name: env # contains the env file with target OpsMan Information
- name: vars # variable files to be made available
optional: true
- name: secrets
# secret files to be made available
# separate from vars, so they can be store securely
optional: true
- name: ops-files # operations files to custom configure the product
optional: true
params:
CONFIG_FILE:
# - Required
# - Filepath to the product configuration yaml file
# - The path is relative to the root of the `config` input
VARS_FILES:
# - Optional
# - Filepath to the product configuration vars yaml file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
OPS_FILES:
# - Optional
# - Filepath to the product configuration operations yaml files
# - The path is relative to root of the task build
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `env` input
run:
path: platform-automation-tasks/tasks/configure-product.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
ops_files_args=("")
for of in ${OPS_FILES}
do
ops_files_args+=("--ops-file ${of}")
done
${vars_files_args[@] needs to be globbed to pass through properly
${ops_files_args[@] needs to be globbed to pass through properly
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: config # contains the auth configuration
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
AUTH_CONFIG_FILE: auth.yml
# - Required
# - Filepath of the authorization config YAML
# - The path is relative to root of the config input
VARS_FILES:
# - Optional
# - Filepath to the Ops Manager vars yaml file
# - The path is relative to root of the task build,
# so vars and secrets can be used.
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" configure-saml-authentication \
--config config/"${AUTH_CONFIG_FILE}" \
${vars_files_args[@]}
!!! info "Bosh Admin Client"
By default, this task creates a bosh admin client.
This is helpful for some advanced workflows
that involve communicating directly with the BOSH Director.
It is possible to disable this behavior;
see our [config file documentation][generating-an-auth-file] for details.
Configuring SAML has two different auth flows for the UI and the task.
The UI will have a browser based login flow.
The CLI will require `client-id` and `client-secret` as it cannot do a browser login flow.
For more details on using SAML,
please refer to the [Ops Manager documentation][config-saml]
For details on the config file expected in the `config` input,
please see [Generating an Auth File][generating-an-auth-file].
### create-vm
Creates an unconfigured Ops Manager VM.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: state # contains the state for the vm
- name: config # contains the product configuration file
- name: image # contains the image file to be installed
- name: vars # variable files to be made available
optional: true
- name: secrets
# secret files to be made available
# separate from vars, so they can be store securely
optional: true
outputs:
- name: generated-state #contains the updated state file
params:
VARS_FILES:
# - Optional
# - Filepath to the Ops Manager vars yaml file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
OPSMAN_CONFIG_FILE: opsman.yml
# - Required
# - Filepath of the opsman config YAML
# - The path is relative to root of the `config` input
STATE_FILE: state.yml
# - Required
# - Filepath of the state yaml file
# - The path is relative to root of the `state` output
# - if the filename includes "$timestamp",
# for example "state-$timestamp.yml",
# the final filename will include the current timestamp.
# - this is necessary if using an "S3 compatible" blobstore
# that doesn't support versioned blobs
# - timestamped filenames will need to be represented
# with a glob-style wildcard in tasks that use this state file
# (such as state-*.yml)
run:
path: platform-automation-tasks/tasks/create-vm.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
'$timestamp' must be a literal, because envsubst uses it as a filter
this allows us to avoid accidentally interpolating anything else.
This task requires a config file specific to the IaaS being deployed to.
Please see the configuration page for more specific examples.
The task does specific CLI commands for the creation of the Ops Manager VM on each IAAS. See below for more information:
AWS
Requires the image YAML file from Pivnet
Validates the existence of the VM if defined in the statefile, if so do nothing
Chooses the correct ami to use based on the provided image YAML file from Pivnet
Creates the vm configured via opsman config and the image YAML. This only attaches existing infrastructure to a newly created VM. This does not create any new resources
The public IP address, if provided, is assigned after successful creation
Azure
Requires the image YAML file from Pivnet
Validates the existence of the VM if defined in the statefile, if so do nothing
Copies the image (of the OpsMan VM from the specified region) as a blob into the specified storage account
Creates the Ops Manager image
Creates a VM from the image. This will use unmanaged disk (if specified), and assign a public and/or private IP. This only attaches existing infrastructure to a newly createdVM. This does not create any new resources.
GCP
Requires the image YAML file from Pivnet
Validates the existence of the VM if defined in the statefile, if so do nothing
Creates a compute image based on the region specific Ops Manager source URI in the specified Ops Manager account
Creates a VM from the image. This will assign a public and/or private IP address, VM sizing, and tags. This does not create any new resources.
Openstack
Requires the image YAML file from Pivnet
Validates the existence of the VM if defined in the statefile, if so do nothing
Recreates the image in openstack if it already exists to validate we are using the correct version of the image
Creates a VM from the image. This does not create any new resources
The public IP address, if provided, is assigned after successful creation
Vsphere
Requires the OVA image from Pivnet
Validates the existence of the VM if defined in the statefile, if so do nothing
Build ipath from the provided datacenter, folder, and vmname provided in the config file. The created VM is stored on the generated path. If folder is not provided, the vm will be placed in the datacenter.
Creates a VM from the image provided to the create-vm command. This does not create any new resources
credhub-interpolate
Interpolate credhub entries into configuration files
Each one of these files will have their values interpolated from credhub.
For examples, run: credhub interpolate --help
(minimum version >= 2.1.0 required)
outputs:
- name: interpolated-files
Contains only yaml files found and interpolated by this task.
Maintains the filestructure of the files input.
all params are required to be filled out
params:
CREDHUB_CLIENT:
CREDHUB_SECRET:
CREDHUB_SERVER:
# - Required
# - Credentials to talk to credhub server
CREDHUB_CA_CERT:
# - Optional
# - This is only necessary if your Concourse worker
# is not already configured to trust the CA used for Credhub.
# - If more than one CA cert is required (ie the UAA),
# the CA certs can be concatenated together and separated by a newline.
# For example,
# CREDHUB_CA_CERT: |
# -----BEGIN CERTIFICATE-----
# ...credhub cert...
# -----END CERTIFICATE-----
# -----BEGIN CERTIFICATE-----
# ...UAA cert...
# -----END CERTIFICATE-----
PREFIX:
# - Required
# - Prefix flag used by credhub interpolate
INTERPOLATION_PATHS: '.'
# - Required
# - Path the contains the files to read from
# - This is a space separated list of directories
# the paths are all evaluated relative to files/
SKIP_MISSING: true
# Optional
# Change to false to have strict interpolation
# and fail if params are missing from vars
```bash tab="Implementation"
cat /var/version && echo ""
set -euo pipefail
# NOTE: The credhub cli does not ignore empty/null environment variables.
# https://github.com/cloudfoundry-incubator/credhub-cli/issues/68
if [ -z "$CREDHUB_CA_CERT" ]; then
unset CREDHUB_CA_CERT
fi
credhub --version
if [ -z "$PREFIX" ]; then
echo "Please specify a PREFIX. It is required."
exit 1
fi
# $INTERPOLATION_PATHS needs to be globbed to read multiple files
# shellcheck disable=SC2086
files=$(cd files && find $INTERPOLATION_PATHS -type f -name '*.yml' -follow)
if [ "$SKIP_MISSING" == "true" ]; then
export SKIP_MISSING="--skip-missing"
else
export SKIP_MISSING=""
fi
for file in $files; do
echo "interpolating files/$file"
mkdir -p interpolated-files/"$(dirname "$file")"
credhub interpolate --prefix "$PREFIX" \
--file files/"$file" "${SKIP_MISSING}" \
> interpolated-files/"$file"
done
This task requires a valid credhub with UAA client and secret. For information on how to
set this up, see [Secrets Handling][secrets-handling]
### delete-installation
Delete the Ops Manager Installation
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `env` input
run:
path: platform-automation-tasks/tasks/delete-installation.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" delete-installation --force
Deletes the Ops Manager VM instantiated by create-vm.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: state # contains the state for the vm
- name: config # contains the product configuration file
- name: vars # variable files to be made available
optional: true
- name: secrets
# secret files to be made available
# separate from vars, so they can be store securely
optional: true
outputs:
- name: generated-state #contains the updated state file
params:
VARS_FILES:
# - Optional
# - Filepath to the Ops Manager vars yaml file
# - The path is relative to root of the task build,
# so vars and secrets can be used.
OPSMAN_CONFIG_FILE: opsman.yml
# - Required
# - Filepath of the opsman config YAML
# - The path is relative to root of the config input
STATE_FILE: state.yml
# - Required
# - Filepath of the state yaml file
# - The path is relative to root of the state output
# - if the filename includes "$timestamp",
# for example "state-$timestamp.yml",
# the final filename will include the current timestamp.
# - this is necessary if using an "S3 compatible" blobstore
# that doesn't support versioned blobs
# - timestamped filenames will need to be represented
# with a glob-style wildcard in tasks that use this state file
# (such as state-*.yml)
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
INPUT_STATE_FILE="$(echo "$STATE_FILE" | env timestamp='*' envsubst '$timestamp')"
# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
OUTPUT_FILE_NAME="$(echo "$STATE_FILE" | env timestamp="$(date '+%Y%m%d.%-H%M.%S+%Z')" envsubst '$timestamp')"
GENERATED_STATE_FILE_NAME="$(basename "$OUTPUT_FILE_NAME")"
# ${vars_files_args[@] needs to be globbed to split properly (SC2068)
# INPUT_STATE_FILE need to be globbed (SC2086)
# shellcheck disable=SC2068,SC2086
p-automator delete-vm \
--config "config/${OPSMAN_CONFIG_FILE}" \
--state-file state/${INPUT_STATE_FILE} \
${vars_files_args[@]}
# INPUT_STATE_FILE need to be globbed (SC2086)
# shellcheck disable=SC2086
cp state/${INPUT_STATE_FILE} "generated-state/${GENERATED_STATE_FILE_NAME}"
This task requires the [state file][state] generated [create-vm](#create-vm).
The task does specific CLI commands for the deletion of the Ops Manager VM and resources on each IAAS. See below for more information:
**AWS**
1. Deletes the VM
**Azure**
1. Deletes the VM
1. Attempts to delete the associated disk
1. Attempts to delete the associated nic
1. Attempts to delete the associated image
**GCP**
1. Deletes the VM
1. Attempts to delete the associated image
**Openstack**
1. Deletes the VM
1. Attempts to delete the associated image
**vSphere**
1. Deletes the VM
### download-product
!!! warning "Ops Manager 2.5"
The filename for the artifact downloaded from Ops Manager is changed! If your resources or pipelines
have a regex for the Ops Manager filename, you **may** be affected. (Please see
Ops Manager's [official notice](https://community.pivotal.io/s/article/ops-manager-2-5-changing-the-file-naming-scheme-might-break-the-pipeline-jobs)
for more information)
Downloads a product specified in a config file from Pivnet, S3, GCS, or Azure.
Optionally, also downloads the latest stemcell for that product.
Downloads are cached, so files are not re-downloaded each time.
When downloading from Pivnet,
the cached file is verified
using the Pivnet checksum
to validate the integrity of that file.
If it does not, the file is re-downloaded.
When downloading from a supported blobstore
the cached file is not-verified,
as there is no checksum from those blobstore APIs to use.
Outputs can be persisted to any supported blobstore using a `put` to an appropriate resource
for later use with download-product using the `SOURCE` parameter,
or used directly as inputs to [upload-and-stage-product](#upload-and-stage-product)
and [upload-stemcell](#upload-stemcell) tasks.
This task requires a [download-product config file][download-product-config].
If stemcell-iaas is specified in the [download-product config file][download-product-config],
and the specified product is a `.pivotal` file,
`download-product` will attempt to download the stemcell for the product.
It will retrieve the latest compatible stemcell for the specified IaaS.
The valid IaaSs are:
- `aws`
- `azure`
- `google`
- `openstack`
- `vsphere`
If a configuration for S3, GCS, or Azure is present in the [download-product config file][download-product-config],
the slug and version of the downloaded product file will be prepended in brackets to the filename.
For example:
- original-pivnet-filenames:
```
ops-manager-aws-2.5.0-build.123.yml
cf-2.5.0-build.45.pivotal
```
- download-product-filenames if blobstore configuration is present:
```
[ops-manager,2.5.0]ops-manager-aws-2.5.0-build.123.yml
[elastic-runtime,2.5.0]cf-2.5.0-build.45.pivotal
```
This is to allow the same config parameters
that let us select a file from Pivnet
select it again when pulling from the supported blobstore.
Note that the filename will be unchanged
if supported blobstore keys are not present in the configuration file.
This avoids breaking current pipelines.
!!! warning "When using the s3 resource in concourse"
If you are using a `regexp` in your s3 resource definition that explicitly requires the pivnet filename to be the _start_ of the
regex, (i.e., the pattern starts with `^`) this won't work when using S3 config.
The new file format preserves the original filename, so it is still possible to match on that -
but if you need to match from the beginning of the filename, that will have been replaced by the prefix described above.
!!! info "When specifying Pivotal Application Service-Windows"
This task will automatically download and inject the winfs for pas-windows.
!!! warning "When specifying Pivotal Application Service-Windows on Vsphere"
This task cannot download the stemcell for pas-windows on vSphere.
To build this stemcell manually, please reference the
[Creating a vSphere Windows Stemcell][create-vsphere-windows-stemcell] guide
in Pivotal Documentation.
!!! info "When only downloading from Pivnet"
When the download product config only has Pivnet credentials,
it will not add the prefix to the downloaded product.
For example, `example-product.pivotal` from Pivnet will be outputed
as `example-product.pivotal`.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: config # contains download-file config file
- name: vars # variable files to be made available
optional: true
- name: secrets
# secret files to be made available
# separate from vars, so they can be store securely
optional: true
outputs:
- name: downloaded-product
- name: downloaded-stemcell
- name: assign-stemcell-config
caches:
- path: downloaded-files
params:
CONFIG_FILE: download-config.yml
# - Required
# - Filepath to the product configuration yaml file
# - The path is relative to the root of the `config` input
VARS_FILES:
# - Optional
# - Filepath to the product configuration vars yaml file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
SOURCE: pivnet
# - Required
# - The source location where products and stemcells are downloaded from.
# - Values: pivnet, s3, gcs, azure
run:
path: platform-automation-tasks/tasks/download-product.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
if [ -z "$SOURCE" ]; then
echo "No source was provided."
echo "Please provide pivnet, s3, gcs, or azure."
exit 1
fi
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
${vars_files_args[@] needs to be globbed to pass through properly
{ printf "\nChecking if product needs winfs injected..."; } 2> /dev/null
if [ "$product_slug" == "pas-windows" ] && [ "$SOURCE" == "pivnet" ]; then
TILE_FILENAME="$(basename "$product_file")"
# The winfs-injector determines the necessary windows image,
# and uses the CF-foundation dockerhub repo
# to pull the appropriate Microsoft-hosted foreign layer.
winfs-injector \
--input-tile "$product_file" \
--output-tile "downloaded-product/${TILE_FILENAME}"
else
cp "$product_file" downloaded-product
fi
if [ -e "$stemcell_file" ]; then
cp "$stemcell_file" downloaded-stemcell
fi
if [ -e downloaded-files/assign-stemcell.yml ]; then
cp downloaded-files/assign-stemcell.yml assign-stemcell-config/config.yml
fi
### download-product-s3
!!! warning "Deprecation Notice"
This task is deprecated in favor of [`download-product`][download-product],
which can now download from all supported blobstores.
Usage has been changed to reflect the preferred command.
Downloads a product specified in a config file from an S3-compatible blobstore.
This is useful when retrieving assets in an offline environment.
Downloads are cached, so files are not re-downloaded each time.
This is intended to be used with files downloaded from Pivnet by [`download-product`][download-product]
and then persisted to a blobstore using a `put` step.
Outputs can be used directly as an input to [upload-and-stage-product](#upload-and-stage-product)
and [upload-stemcell](#upload-stemcell) tasks.
This task requires a [download-product config file][download-product-config].
The same configuration file should be used with both this task and [`download-product`][download-product].
This ensures that the same file
is being captured with both tasks.
The product files uploaded to s3 for download with this task require a specific prefix:
`[product-slug,semantic-version]`.
This prefix is added by the [`download-product`][download-product] task
when S3 keys are present in the configuration file.
This is the meta information about the product from Pivnet,
which is _not guaranteed_ to be in the original filename.
This tasks uses the meta information to be able to perform
consistent downloads from s3
as defined in the provided download config.
For example:
- original-pivnet-filenames:
```
ops-manager-aws-2.5.0-build.123.yml
cf-2.5.0-build.45.pivotal
```
- filenames expected by `download-product-s3` in a bucket:
```
[ops-manager,2.5.0]ops-manager-aws-2.5.0-build.123.yml
[elastic-runtime,2.5.0]cf-2.5.0-build.45.pivotal
```
!!! info "When only downloading from Pivnet"
When the download product config only has Pivnet credentials,
it will not add the prefix to the downloaded product.
For example, `example-product.pivotal` from Pivnet will be outputed
as `example-product.pivotal`.
!!! info
It's possible to use IAM instance credentials
instead of providing S3 creds in the config file.
See [download-product config file][download-product-config] for details.
```yaml tab="Task"
# DEPRECATION NOTICE:
# The download-product-s3 task will be replaced with the download-product task.
# That task will support the SOURCE param for downloading from pivnet, s3, gcs, or azure.
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: config # contains download-file config file
- name: vars # variable files to be made available
optional: true
- name: secrets
# secret files to be made available
# separate from vars, so they can be store securely
optional: true
outputs:
- name: downloaded-product
- name: downloaded-stemcell
- name: assign-stemcell-config
caches:
- path: downloaded-files
params:
CONFIG_FILE: download-config.yml
# - Required
# - Filepath to the product configuration yaml file
# - The path is relative to the root of the `config` input
VARS_FILES:
# - Optional
# - Filepath to the product configuration vars yaml file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
run:
path: platform-automation-tasks/tasks/download-product-s3.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
echo "DEPRECATION NOTICE:"
echo "The download-product-s3 task will be replaced with the download-product task."
echo "That task will support the SOURCE param for downloading from pivnet, s3, gcs, or azure."
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
${vars_files_args[@] needs to be globbed to pass through properly
Returns a list of certificates that are expiring within a time frame.
These certificates can be Ops Manager or Credhub certificates.
Root CAs cannot be included in this list until Ops Manager 2.7.
This is purely an informational task.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
EXPIRES_WITHIN:
# - Required
# - Example: "3m" is 3 months
# - Check for certificates expiring within the defined time period
# - Supports a time period defined with a suffix of:
# days(d), weeks(w), months(m) and years(y)
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
if [ -z "$EXPIRES_WITHIN" ]; then
echo "The parameter EXPIRES_WITHIN is required"
exit 1
fi
om --env env/"${ENV_FILE}" expiring-certificates \
--expires-within "$EXPIRES_WITHIN"
### export-installation
Exports an existing Ops Manager to a file.
This is the first part of the backup/restore and upgrade lifecycle processes.
This task is used on a fully installed and healthy Ops Manager to export
settings to an upgraded version of Ops Manager.
To use with non-versioned blobstore, you can override `INSTALLATION_FILE` param
to include `$timestamp`, then the generated installation file will include a sortable
timestamp in the filename.
example:
```yaml
params:
INSTALLATION_FILE: installation-$timestamp.zip
Info
The timestamp is generated using the time on concourse worker.
If the time is different on different workers, the generated timestamp may fail to sort correctly.
Changing the time or timezone on workers might interfere with ordering.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
outputs:
- name: installation # will contain the exported installation
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
INSTALLATION_FILE: installation-$timestamp.zip
# - Required
# - Filepath of the installation ZIP file
# - The path is relative to root of the installation output
# - if the filename includes "$timestamp",
# for example "installation-$timestamp.zip",
# the final filename will include the current timestamp.
# - this is necessary if using an "S3 compatible" blobstore
# that doesn't support versioned blobs
# - timestamped filenames will need to be represented
# with a glob-style wildcard in the upgrade-opsman task configuration
# (the default will work with the example provided above).
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
timestamp="$(date '+%Y%m%d.%-H%M.%S+%Z')"
export timestamp
# '$timestamp' must be a literal, because envsubst uses it as a filter
# this allows us to avoid accidentally interpolating anything else.
# shellcheck disable=SC2016
OUTPUT_FILE_NAME="$(echo "$INSTALLATION_FILE" | envsubst '$timestamp')"
om --env env/"${ENV_FILE}" export-installation \
--output-file installation/"$OUTPUT_FILE_NAME"
!!! warning "Always Export your Installation"
It is recommended to persist the zip file exported from export-installation
to an external file store (eg S3) on a regular basis.
The exported installation can restore the Ops Manager
to a working state if it is non-functional.
### import-installation
Imports a previously exported installation to Ops Manager.
This is a part of the backup/restore and upgrade lifecycle processes.
This task is used after an installation has been exported and a new Ops Manager
has been deployed, but before the new Ops Manager is configured.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the environment information about the OpsMan
- name: installation # contains the installation to be imported
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the environment config YAML
# - The path is relative to root of the `env` input
# - The env file _must_ contain the `decryption-passphrase`
# while it's optional for other tasks, this one requires it.
INSTALLATION_FILE: installation*.zip
# - Required
# - Filepath of the installation ZIP file
# - The filepath provided can be wildcard expanded.
# - The path is relative to root of the `installation` input
run:
path: platform-automation-tasks/tasks/import-installation.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
INSTALLATION_FILE needs to be globbed
shellcheck disable=SC2086
om --env env/"${ENV_FILE}" import-installation \
--installation installation/$INSTALLATION_FILE
This commits all changes present
in the repo used for the repository input,
in addition to copying in a single file.
Info
This does not perform a git push!
You will need to put the output of this task to a git resource to persist it.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: repository
# - This must be an initialized git repository.
# - Note that any changes present in this input
# will be committed along with the file copied in
# by this task.
- name: file-source
# - This is the input folder containing the file to be committed.
# Typically, this will from some other task
# with an output that needs to be persisted.
outputs:
- name: repository-commit
params:
FILE_SOURCE_PATH:
# - Required
# - Filepath to be copied into the git repo
# before a commit is created
# - Relative to the root of the file-source input
FILE_DESTINATION_PATH:
# - Required
# - Filepath to write the file specified by FILE_SOURCE_PATH
# - Relative to the root of the repository input
GIT_AUTHOR_NAME:
# - Required
# - Used to configure the human-readable
# name in the author field of the commit
GIT_AUTHOR_EMAIL:
# - Required
# - Used to configure the email address
# in the author field of the commit
COMMIT_MESSAGE:
# - Required
# - Specify a commit message to be used
# for all commits made by this task.
### pre-deploy-check
Checks if the Ops Manager director is configured properly and validates the configuration.
This feature is only available in Ops Manager 2.6+.
Additionally, checks each of the staged products
and validates they are configured correctly.
This task can be run at any time
and can be used a a pre-check for [`apply-changes`][apply-changes].
The checks that this task executes are:
- is configuration complete and valid
- is the network assigned
- is the availability zone assigned
- is the stemcell assigned
- what stemcell type/version is required
- are there any unset/invalid properties
- did any ops manager verifiers fail
If any of the above checks fail
the task will fail.
The failed task will provide a list of errors that need to be fixed
before an `apply-changes` could start.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `env` input
run:
path: platform-automation-tasks/tasks/pre-deploy-check.sh
### stage-configure-apply
This is an _advanced task_.
Stage a product to Ops Manager, configure that product, and apply changes
only to that product without applying changes to the rest of the foundation.
!!! info
Ops Manager Verifier failures when applying changes will prevent deployment.
In cases where these verifiers are incorrectly failing for known reasons,
they should be disabled [using om][disable-verifiers].
The ` --ignore-warnings` option for `om apply-changes`
allows users to ignore all warnings from ignorable verifiers.
This option is not available in Platform Automation.
In an automation context, disabling _only the particular verifiers_
where failure is well-understood allows other verifiers
to continue to provide important feedback.
[apply-changes]: tasks.md#apply-changes
[apply-director-changes]: tasks.md#apply-director-changes
[assign-stemcell]: tasks.md#assign-stemcell
[assign-multi-stemcell]: tasks.md#assign-multi-stemcell
[auth-file]: how-to-guides/configuring-auth.md#generating-an-auth-file
[check-pending-changes]: tasks.md#check-pending-changes
[collect-telemetry]: tasks.md#collect-telemetry
[config-template]: how-to-guides/creating-a-product-config-file.md#from-pivnet
[configure-authentication]: tasks.md#configure-authentication
[configure-director]: tasks.md#configure-director
[configure-ldap-authentication]: tasks.md#configure-ldap-authentication
[configure-product]: tasks.md#configure-product
[configure-saml-authentication]: tasks.md#configure-saml-authentication
[create-vm]: tasks.md#create-vm
[credhub-interpolate]: tasks.md#credhub-interpolate
[delete-vm]: tasks.md#delete-vm
[director-configuration]: how-to-guides/creating-a-director-config-file.md
[disable-verifiers]: how-to-guides/running-commands-locally.md#disable-verifiers
[download-product-config]: inputs-outputs.md#download-product-config
[download-stemcell-product-config]: inputs-outputs.md#download-stemcell-product-config
[download-product]: tasks.md#download-product
[download-product-s3]: tasks.md#download-product-s3
[env]: inputs-outputs.md#env
[expiring-certificates]: tasks.md#expiring-certificates
[export-installation]: tasks.md#export-installation
[externalized-tile-config]: pipeline-design/externalized-configuration.md#using-externalized-tile-configuration
[fly-download-image]: img/concourse-fly-download.png
[generating-an-auth-file]: how-to-guides/configuring-auth.md#generating-an-auth-file
[generating-env-file]: how-to-guides/configuring-env.md#generating-an-env-file
[getting-started]: getting-started.md
[git-repo-layout]: how-to-guides/git-repo-layout.md#recommended-file-structure
[iaas-cli-errors]: concepts/upgrade.md#iaas-cli-errors
[import-installation]: tasks.md#import-installation
[inputs-outputs]: inputs-outputs.md
[inputs-outputs-aws]: inputs-outputs.md#aws
[inputs-outputs-azure]: inputs-outputs.md#azure
[inputs-outputs-gcp]: inputs-outputs.md#gcp
[inputs-outputs-vsphere]: inputs-outputs.md#vsphere
[installation]: inputs-outputs.md#installation
[install-how-to]: how-to-guides/installing-opsman.md
[overview]: index.md
[multi-foundation-secrets-handling]: concepts/secrets-handling.md#storing-values-for-multi-foundation
[opsman-config]: inputs-outputs.md#ops-manager-config
[opsman-image]: inputs-outputs.md#opsman-image
[pre-deploy-check]: tasks.md#pre-deploy-check
[prepare-tasks-with-secrets]: tasks.md#prepare-tasks-with-secrets
[prepare-tasks-with-secrets-how-to]: concepts/secrets-handling.md#using-prepare-tasks-with-secrets
[prepare-tasks-with-secrets-replace]: concepts/secrets-handling.md#replacing-credhub-interpolate-with-prepare-tasks-with-secrets
[product-configuration]: how-to-guides/creating-a-product-config-file.md
[product-configuration-from-pivnet]: how-to-guides/creating-a-product-config-file.md#from-pivnet
[reference-pipeline]: pipelines/multiple-products.md
[reference-resources]: pipelines/resources.md
[reference-pipeline-pks]: pipelines/single-product.md
[running-commands-locally]: how-to-guides/running-commands-locally.md
[secrets-handling]: concepts/secrets-handling.md
[secrets-handling-multiple-sources]: concepts/secrets-handling.md#multiple-sources
[semantic-versioning]: compatibility-and-versioning.md#semantic-versioning
[send-telemetry]: tasks.md#send-telemetry
[setup-s3-and-resources]: how-to-guides/setting-up-s3.md
[single-foundation-pattern]: pipeline-design/configuration-management-strategies.md#single-repository-for-each-foundation
[stage-configure-apply]: tasks.md#stage-configure-apply
[stage-product]: tasks.md#stage-product
[staged-config]: tasks.md#staged-config
[staged-director-config]: tasks.md#staged-director-config
[state]: inputs-outputs.md#state
[stemcell-handling]: concepts/stemcell-handling.md
[task-reference]: tasks.md
[telemetry-config]: inputs-outputs.md#telemetry
[test]: tasks.md#test
[test-interpolate]: tasks.md#test-interpolate
[upgrade-how-to]: how-to-guides/upgrade-existing-opsman.md
[upgrade-opsman]: tasks.md#upgrade-opsman
[upload-product]: tasks.md#upload-product
[upload-stemcell]: tasks.md#upload-stemcell
[uploaded-and-staged]: tasks.md#upload-and-stage-product
[variables]: concepts/variables.md
[version-check-errors]: concepts/upgrade.md#version-check-errors
[vm-extensions]: how-to-guides/creating-a-director-config-file.md#vm-extensions
[vm-types]: how-to-guides/creating-a-director-config-file.md#vm-types
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: config # contains the product configuration file
- name: env # contains the env file with target OpsMan Information
- name: vars # variable files to be made available
optional: true
- name: secrets
# secret files to be made available
# separate from vars, so they can be store securely
optional: true
- name: ops-files # operations files to custom configure the product
optional: true
- name: product # contains the product file to be staged
params:
CONFIG_FILE:
# - Required
# - Filepath to the product configuration yaml file
# - The path is relative to the root of the `config` input
VARS_FILES:
# - Optional
# - Filepath to the product configuration vars yaml file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
OPS_FILES:
# - Optional
# - Filepath to the product configuration operations yaml files
# - The path is relative to root of the task build
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `env` input
ALLOW_PENDING_CHANGES: false
# - Optional
# - If false, will fail if there are pending changes in OpsMan
run:
path: platform-automation-tasks/tasks/stage-configure-apply.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
platform-automation-tasks/tasks/check-pending-changes.sh
platform-automation-tasks/tasks/stage-product.sh
platform-automation-tasks/tasks/configure-product.sh
Staged a product to the Ops Manager specified in the config file.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: product # contains the product file to be staged
- name: env # contains the env file with target OpsMan Information
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
### staged-config
Downloads the configuration for a product from Ops Manager.
Not to be confused with Ops Manager's
built-in [export][bbr-export],
which puts all deployed products and configurations into a single file,
intended for import as part of backup/restore and upgrade lifecycle processes.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
outputs:
- name: generated-config # will contain the staged product config
params:
PRODUCT_NAME:
# - Required
# - The name of the product config to be exported
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the `env` input
SUBSTITUTE_CREDENTIALS_WITH_PLACEHOLDERS: true
# - Optional
# - Replace credentials with interpolatable variable names
# - If set to false, **literal credentials** will be included in the output
run:
path: platform-automation-tasks/tasks/staged-config.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
flag=$(if "$SUBSTITUTE_CREDENTIALS_WITH_PLACEHOLDERS";
then echo '--include-placeholders';
else echo '--include-credentials';
fi
)
The filename for the artifact downloaded from Ops Manager is changed! If your resources or pipelines
have a regex for the Ops Manager filename, you may be affected. (Please see
Ops Manager's official notice
for more information)
Downloads configuration for the BOSH director from Ops Manager.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
outputs:
- name: generated-config # will contain the staged product config
params:
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
The configuration is exported to the `generated-config` output.
It does not extract credentials from Ops Manager
and replaced them all with YAML interpolation `(())` placeholders.
This is to ensure that credentials are never written to disk.
The credentials need to be provided from an external configuration when invoking [configure-director](#configure-director).
!!! info
staged-director-config will not be able to grab all sensitive fields in your Ops Manager installation
(for example: vcenter_username and vcenter_password if using vsphere). To find these missing fields, please refer to the [Ops Manager API Documentation][opsman-api]
### test
An example task to ensure the assets and docker image are setup correctly in your concourse pipeline.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
run:
path: platform-automation-tasks/tasks/test.sh
set -eux
p-automator --help
om --help
{ echo "Successfully validated tasks and image!"; } 2> /dev/null
1234
```yaml tab="Usage"
- task: test
file: platform-automation-tasks/tasks/test.yml
image: platform-automation-image
test-interpolate
An example task to ensure that all required vars are present when interpolating into a base file.
For more instruction on this topic, see the variables section
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: config # contains the base configuration file
- name: vars # variable files to be made available
optional: true
params:
VARS_FILES:
# - Optional
# - Filepath to the vars yaml file
# - The path is relative to root of the task build,
# so vars and secrets can be used.
CONFIG_FILE: base.yml
# - Required
# - Filepath to the base yaml file to interpolate from
# - The path is relative to root of the task build
SKIP_MISSING: true
# - Optional
# - Change to false to have strict interpolation
# and fail if params are missing from vars
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
if [ "$SKIP_MISSING" == "true" ]; then
export SKIP_MISSING="--skip-missing"
else
export SKIP_MISSING=""
fi
# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om interpolate --config "config/$CONFIG_FILE" "$SKIP_MISSING" ${vars_files_args[@]}
### upgrade-opsman
Upgrades an existing Ops Manager to a new given Ops Manager version
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: state # contains the state for the vm
- name: config # contains the OpsMan configuration file
- name: image # contains the image file to be installed
- name: installation # contains the installation to be imported
- name: env # contains the environment information for OpsMan
- name: vars # variable files to be made available
optional: true
- name: secrets # secret files to be made available
# separate from vars, so they can be stored securely
optional: true
outputs:
- name: generated-state #contains the updated state file
params:
VARS_FILES:
# - Optional
# - space-seperated array of filepaths to YAML vars files
# to be loaded with the OPSMAN_CONFIG_FILE
# - relative to root of the task build,
# so both `vars` and `secrets` can be used.
ENV_FILE: env.yml
# - Required
# - filepath of the env config YAML
# - relative to root of the `env` input
OPSMAN_CONFIG_FILE: opsman.yml
# - Required
# - filepath of the opsman config YAML
# - relative to root of the `config` input
STATE_FILE: state.yml
# - Required
# - Filepath of the state yaml file
# - The path is relative to root of the `state` output
# - if the filename includes "$timestamp",
# for example "state-$timestamp.yml",
# the final filename will include the current timestamp.
# - this is necessary if using an "S3 compatible" blobstore
# that doesn't support versioned blobs
# - timestamped filenames will need to be represented
# with a glob-style wildcard in tasks that use this state file
# (such as state-*.yml)
INSTALLATION_FILE: installation*.zip
# - Required
# - filepath of the installation ZIP file
# - can be wildcard expanded
# - relative to root of the `installation` input
run:
path: platform-automation-tasks/tasks/upgrade-opsman.sh
```bash tab="Implementation"
cat /var/version && echo ""
p-automator -v
set -eux
vars_files_args=("")
for vf in ${VARS_FILES}
do
vars_files_args+=("--vars-file ${vf}")
done
'$timestamp' must be a literal, because envsubst uses it as a filter
this allows us to avoid accidentally interpolating anything else.
For more information about this task and how it works, see the upgrade page.
upload-and-stage-product
Uploads and stages product to the Ops Manager specified in the config file.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: product # contains the product file to be uploaded and staged
- name: env # contains the env file with target OpsMan Information
- name: config # contains the product configuration file
optional: true
params:
CONFIG_FILE:
# - Optional
# - Path to the config file for the product
# - Relative to the root of the config input
# - If empty, no config will be used; version and sha256 will not be checked
# - Example config:
# ---
# product-version: 1.2.3-build.4
# sha256: 6daededd8fb4c341d0cd437a669d732d2fde62cb89716498e6b16f34607a1498
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
### upload-product
Uploads a product to the Ops Manager specified in the config file.
If a shasum is provided in the config.yml,
the integrity product will be verified
with that shasum before uploading.
```yaml tab="Task"
---
platform: linux
inputs:
- name: platform-automation-tasks
- name: product # contains the product file to be uploaded and staged
- name: env # contains the env file with target OpsMan Information
- name: config # contains the product configuration file
optional: true
params:
CONFIG_FILE:
# - Optional
# - Path to the config file for the product
# - Relative to the root of the `config` input
# - If empty, no config will be used; version and sha256 will not be checked
# - Example config:
# ---
# product-version: 1.2.3-build.4
# shasum: 6daededd8fb4c341d0cd437a669d732d2fde62cb89716498e6b16f34607a1498
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - Relative to root of the `env` input
run:
path: platform-automation-tasks/tasks/upload-product.sh
```bash tab="Implementation"
cat /var/version && echo ""
set -eux
export OPTIONAL_CONFIG_FLAG=""
if [ -n "$CONFIG_FILE" ]; then
export OPTIONAL_CONFIG_FLAG="--config config/$CONFIG_FILE"
fi
shellcheck disable=SC2086
om --env env/"${ENV_FILE}" upload-product \
--product product/*.pivotal \
$OPTIONAL_CONFIG_FLAG
Note that the filename of the stemcell must be exactly as downloaded from Pivnet.
Ops Manager parses this filename to determine the version and OS of the stemcell.
```yaml tab="Task"
platform: linux
inputs:
- name: platform-automation-tasks
- name: env # contains the env file with target OpsMan Information
- name: stemcell # contains the stemcell tarball
- The stemcell filename is important and must be preserved.
if using the bosh.io concourse resource,
set params.preserve_filename: true on your GET.
params:
CONFIG_FILE:
# - Optional
# - Path to the config file for the product
# - Relative to the root of the config input
# - If empty, no config will be used; version and sha256 will not be checked
# - Example config:
# ---
# shasum: 6daededd8fb4c341d0cd437a669d732d2fde62cb89716498e6b16f34607a1498
ENV_FILE: env.yml
# - Required
# - Filepath of the env config YAML
# - The path is relative to root of the env input
FLOATING_STEMCELL: true
# - Optional
# - Assigns the stemcell to all compatible products
# - If false, a user is required to run the assign-stemcell task
