This repo contains concourse tasks for use with cf-deployment. If you are trying to deploy to GCP, you may wish to check the GCP Deployment Guide. Each task is in its own directory. A task will generally be composed of a task.yml to be referenced in pipelines, a supporting task file, and a Dockerfile. The Dockerfile is built and pushed to Dockerhub regularly in CI maintained by the CF Release Integration team here.
It should be clear how to use each task
from the task.yml
and the description below.
If you find that it is not,
please contact the Release Integration team
in our Slack channel dedicated to supporting users of cf-deployment.
Alternatively, you can open an issue.
Development updates to the repo are made to the master branch,
so untested or backwards incompatible changes may be present there.
Once changes have been tested and all stories accepted,
we add new version tags such as v1.6 to the approprate commit.
We use a bare-bones type of semantic versioning for this repo.
Backwards incompatible changes warrant a major version bump (e.g. v1.6 to v2.0),
while other changes will simply add a minor version bump (e.g. v2.0 to v2.1).
In Concourse, you can pretty easily lock to a major version, meaning that your pipeline will take minor (i.e. backwards compatible) changes only. Here's an example from our nats release pipeline:
- name: cf-deployment-concourse-tasks
type: git
source:
branch: master
uri: https://github.com/cloudfoundry/cf-deployment-concourse-tasks.git
tag_filter: v3.*
When you're ready to take the backwards incompatible changes, you can take any necessary manual steps to upgrade, and then change the major version in your pipeline configuration.
Tasks are listed here alphabetically,
along with a brief description
meant to be used alongside the task.yml within each task directory
to understand the tasks'
purpose, interface, and options.
Each title is also a link
to the appropriate task.yml.
This destroys the director and infrastructure created by bbl. Debug output is written to bbl_destroy.txt to help debug failures in this task.
This uses bbl
to create your infrastructure
and deploy a BOSH director.
Debug output
is written to
bbl_up.txt,
bbl_create_lbs.txt,
and bbl_update_lbs.txt
to help debug failures
in this task.
This task requires
a certificate and key
(unless you are bbling up a bosh-lite environment)
which can be generated using
the commands specified here.
This performs a BOSH cleanup which is necessary from time to time to avoid running out of space.
This performs a BOSH deployment and outputs a vars-store. Optionally, operations files may be applied to the deployment manifest.
It's also configurable to regenerate the vars-store on each deployment though this is not the default behavior. This is helpful for testing changes to variable generation, but is only expected to work with fresh deployments.
This creates and applies an
additional operations file to cf-deployment.yml,
which causes BOSH to
create, upload, and use a dev release
from the provided release folder
in place of the version specified in cf-deployment.yml.
This is useful for testing an upstream component.
Otherwise identical to the bosh-deploy task above.
This takes as input
a concourse resource
for the submodule version bumped
when creating a dev release
from the provided release folder.
Otherwise identical to the bosh-deploy-with-created-release task above.
concourse resource.
This uploads the stemcell version
specified in cf-deployment
to the BOSH director.
This collects two sets of operations files. The first set is the "base" set, to which the second ("new") set is added.
If there is a name conflict, the operations file from the second ("new") set wins.
This will toggle the specified feature-flags based on their boolean values.
This updates integration files to be consumed by CATs and RATs with credentials drawn from a vars-store.