release is a job that is used to create a semantically versioned object that represents an immutable list of service definitions, in our case a manifest. The benefit of using this job would be if you have multiple services that make up your application and you want them all to be deployed as a unit.
This job can also be used to simply maintain an incrementing version number, without being associated with any particular set of manifests.
Shippable DevOps Assembly Lines store the service definitions in the versions of the following jobs:
- manifest is a single service definition.
- deploy is a collection of one or more manifests that have been deployed to a cluster.
- release is a collection of one or more manifests that have been associated with a version number.
All of the above jobs can be used as
INs to create a new
release. A new version is created anytime this job is executed.
You can create a
release job by adding it to
shippable.yml and these jobs execute on Shippable provided shared runtime.
jobs: - name: <string> # required type: release # required bump: <bump strategies> # optional, defaults to minor on_start: # optional - NOTIFY: <notification resource name> steps: - IN: <version> # optional - IN: <manifest/release/deploy> # optional - IN: <manifest/release> # optional - IN: <any job or resource> # optional on_success: # optional - NOTIFY: <notification resource name> on_failure: # optional - NOTIFY: <notification resource name> on_cancel: # optional - NOTIFY: <notification resource name> always: # optional - NOTIFY: <notification resource name>
name-- should be an easy to remember text string
type-- is set to
bump-- This is used to control the strategy used to bump your seed version. Subsequent executions of this job will increment the last bumped value if it is semantically greater than the
seed. If you want to reset, then just change the seed and it will start from the new seed again. Below is a list of accepted strategies and how they behave if a seed version of
major-- increments the major bit. So, first pass it will be
v2.0.0and next one will be
minor-- increments the minor bit. So, first pass it will be
v1.1.0and next one will be
patch-- increments the patch bit. So, first pass it will be
v1.0.1and next one will be
alpha-- increments the alpha bit. So, first pass it will be
v1.0.0-alphaand next one will be
beta-- increments the beta bit. So, first pass it will be
v1.0.0-betaand next one will be
rc-- increments the alpha bit. So, first pass it will be
v1.0.0-rcand next one will be
final-- removes pre-release flags on your incoming version, so if your input was
v4.0.0-rc.5, then output version would be
steps-- is an object which contains specific instructions to run this job
IN-- You need at least one source of a semVer string, and one
manifest-based input (
deploy). If you use multiple of them, then they will be deployed as a whole. Below is the list of all Resources and Jobs that can be supplied as
version -- This is used as the seed version that you want to start from. You can also use this to reset the current version back to a specific value. This
INis optional if the job already has another source of a base version (such as a previous
manifest/release/deploy -- You can add zero or more of these. When you add a release job, the version produced from the incoming release job will be used as the base for the
bumpaction instead of the
deploy -- You can add zero or more of these. Since a
deployjob's output is a list of manifests, using it as an
INto a release job will result in that list of manifests being tagged with the version produced by the
Any other job or resource will only participate in triggering
releasejob but not in of the processing of it.
alwaysare used to send notifications for those events. You need to provide a notification resource pointing to the provider like Slack, Email, IRC, Hipchat, etc.
The jobs section of the anatomy of shippable.yml page contains additional descriptions of these tags.
releasejobs are managed jobs, free-form scripting is not allowed.
A new version of the
releasejob is created every time it is executed. Since the job executions are versioned, it is easy to Replay an old version to trigger your Assembly Line with the old settings. However, you should only do so if you understand the impact to your Assembly Lines.