manifest job is used to create a versioned, immutable service definition of a deployable unit of your application. Depending on your use case, the deployment unit could be a service, microservice, or the entire application.
manifest can be supplied as an input to a deploy Job which will then deploy it to the desired target.
manifest can contain the following:
- One or more Docker image Resources OR one or more file Resources as the basic deployable unit.
- optional params Resource to inject environment variables during deployment.
- optional dockerOptions resource for Docker manifests. This helps specify options for the deployed container.
manifest is always deployed as a whole i.e. if it contains multiple images/files, all the images/files will be deployed even if only one changed. If you want them to deployed independently, you should create multiple manifests to represent them.
You can create a
manifest job by adding it to shippable.yml.
jobs: - name: <string> # required type: manifest # required dependencyMode: <chrono/strict/immediate> # optional on_start: # optional - NOTIFY: <notification resource name> steps: - IN: <image/file> # required - IN: <image/file> # optional - IN: <dockerOptions> # optional - IN: <dockerOptions> # optional applyTo: - <image> - <image> - IN: <params> # optional - IN: <params> # optional applyTo: - <image/file> - <image/file> - IN: <replicas> # 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
dependencyMode-- Optional. This may be set to
chrono. For detailed explanation, read about job triggering mechanisms
steps-- is an object which contains specific instructions to run this Job.
dockerOptions -- Optional input for manifests containing image resource. It is used to set specific container options. If more than one is provided, a UNION operation is performed to create an unique set and applied to all the
imageresources. Items are applied in the order they are provided in
steps. If you want
dockerOptionsresource to modify specific entities, use
replicas -- Optional input for manifests containing image resources. It is used to set the number of manifest copies to start when the manifest is deployed. If you specify more than one
replicasresource, the last one overrides any previous ones. This setting will carry forward in your Assembly Line until overridden by another
replicasresource. The count will be ignored if deploying to Amazon ECS with
params -- Optional input, and it works for both
fileinputs. It is used to set environment variables during deployment. If more than one is provided, a UNION operation is performed to create an unique set and applied to all the
fileresources. Items are applied in the order they are provided in
steps. If you want
paramsresource to be associated with specific entities, use
Any other Job or Resource will only participate in triggering
manifestjob, 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.
manifestjobs are managed jobs, free-form scripting is not allowed.
A new version of the
manifestjob 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.