Cruise Configuration Reference
Configuration reference
<cruise>
The <cruise> element is the root element of the configuration.
<server>
The <server> element can be used to define information and attributes of the Cruise Server.
Attributes
| Attribute | Required | Description |
|---|---|---|
| artifactsdir | No | This directory is where Cruise will store its information, including artifacts published by jobs. The default value is 'logs' in the folder where the Cruise Server is installed. You can use an absolute path or a relative path. A relative path will take the server installed folder as the root. Notes: If you specify the attribute, please check that Cruise has permission to access that directory. |
<license>
The <license> element contains your Cruise license. If you don't have one please visit the Cruise Website to obtain one.
Attributes
| Attribute | Required | Description |
|---|---|---|
| user | Yes | the user name in your license |
Examples
<license user="${the user name in your license}">
${license key}
</license>
<security>
The <security> element can be used to enable authentication. If the element is not there, anyone can visit Cruise without sign-in. We currently support LDAP and a simple password file format. You can use both methods if you want. This can be useful if you want to allow access from scripts without having to add a lot of users to your corporate LDAP. In this case you could add a 'script' user to the password file.
<ldap>
The <ldap> element is used to specify the ldap server. Users can access Cruise with their username and password from this ldap server.
Attributes
| Attribute | Required | Description |
|---|---|---|
| uri | Yes | uri for the ldap server. For example, uri="ldap://xxx.yourcompany.com" |
| managerDn | Yes | For example, managerDn="cn=Active Directory Ldap User,ou=InformationSystems,ou=SharedAccounts,ou=Principal,dc=xxxxx,dc=yyyy,dc=com" |
| managerPassword | Yes | Cruise will connect to the LDAP server with this password |
| searchBase | Yes | e.g. searchBase="ou=Employees,ou=Enterprise,ou=Principal,dc=xxxx,dc=yyyy,dc=com" |
| searchFilter | No | e.g. searchFilter="(sAMAccountName={0})" |
<passwordFile>
The <passwordFile> element is used to specify a file which has a set of username and password pairs. The format of username and password in this file is ${username}=${password which has been encrypted with SHA1}, with one line per user.
Attributes
| Attribute | Required | Description |
|---|---|---|
| path | Yes | The absolute path of the password file. |
Examples
Suppose the password file is admins.properties, which is located in /home/cruise. You want to create two users as Administrators:
- one username is Jez, the password encrypted with SHA1 is ThmbShxAtJepX80c2JY1FzOEmUk=
- the other one is lqiao, the password encrypted with SHA1 is TfkgShslgJepX80c2JY1trwEskT=
The configuration could look like:
<security>
<passwordFile path="/home/cruise/admins.properties"/>
</security>
The username and password could be set in admins.properties as follows:
Jez=ThmbShxAtJepX80c2JY1FzOEmUk
lqiao=TfkgShslgJepX80c2JY1trwEskT
<roles>
The <roles> element is a container for roles that users defined. It can't be defined without <role>.
<role>
The <role> element is used to define a group to do particular works. a number of users has to be define in the sub-tag <user>. This is an example.
Notes:- If you want to define roles, you must define an authentication method, either <ldap> or <passwordFile>.
- The roles has nothing to do with the roles in LDAP, and they only work with Cruise. For example, you can assign a role to the manual-approval in a stage, so that only the users in the role can approve the stage to run.
Attributes
| Attribute | Required | Description |
|---|---|---|
| name | Yes | The name of the role. |
<user>
One <user> element is only for one user. You can add as many as you like.
Notes:- The user must be in your LDAP or passwordFile.
- If the same user name exists in both the LDAP and password file, then both of them would be in the role.
Examples
Two users would be in the role 'cruise-admin', they are Jez and lqiao.
<role name="cruise-admin">
<user>Jez</user>
<user>lqiao</user>
</role>
<admins>
The <admins> element specifies which users are administrators. Only administrators can open the Administration tab to maintain Cruise Configuration.
Notes:If you want to specify administrators, you must define an authentication method, either <ldap> or <passwordFile>.
<role>
One <role> element in <admins> is used to specify a group as administrators. You can add as many as you like.
Notes:- The role must refer to <roles>.
Examples
The users in role 'cruise-admin' would be administrators.
<admins>
<role>cruise-admin</role>
<user>lqiao</user>
</admins>
<user>
One <user> element is used to specify one administrator. You can add as many as you like.
Notes:- The user must be in your LDAP or passwordFile.
- If the same user name exists in both the LDAP and password file, then both of them would be administrators.
Examples
Two users would be administrators, they are Jez and lqiao.
<admins>
<user>Jez</user>
<user>lqiao</user>
</admins>
<pipelines>
The <pipelines> element is a container of pipelines.
<pipeline>
The <pipeline> element specifies a single pipeline.
Notes:There should be at least one stage in one pipeline. Cruise uses the pipeline name to identify the pipeline. If you change the pipeline name, you will lose the history of the pipeline.
Attributes
| Attribute | Required | Description |
|---|---|---|
| name | Yes | The name is used to identify a pipeline, so each pipeline name must be unique. Pipeline name can contain the following characters: a-z, A-Z, 0-9, fullstop, underscore and hyphen. Spaces are not allowed. Name is case-insensitive in Cruise and the length should be less than 255 charactors. |
| labeltemplate | No | You can customize a pipeline label with ${COUNT}. The default value is '${COUNT}'. For example, if you specify labeltemplate="foo-1.0-${COUNT}", your pipeline will show foo-1.0-1, foo-1.0-2, and so on. You can only have one ${COUNT} in the labeltemplate. Lower case ${count} is also invalid. The label should be less than 255 charactors. |
<trackingtool>
The <trackingtool> element specifies a link with ${ID} as placeholder. Cruise will construct a link based on the commit message, the link will take you to your tracking tool(Mingle card, JIRA issue, Trac issue and etc) page.
Attributes
| Attribute | Required | Description |
|---|---|---|
| link | Yes | a URL with a string '${ID}'. Cruise will replace the string with the first matched group value on run-time. |
| regex | Yes | regex is the matcher. Cruise will find the first matched group in your commit messages and use it to construct the hyper-link which will link to your tracking tool. |
Examples
Suppose you are using a Web Application to manage your tasks or bugs, and the link looks like http://xxx.xx.xx/yourproject/512, '512' is your task ID. Your configuration would be:
<pipeline name="yourproject">
<trackingtool link="http://xxx.xx.xx/yourproject/${ID}" regex="evo-(\d+)"/>
...
<pipeline name="yourproject">
If you check in some codes with a commit message which include the characters 'evo-512', you will see the underline 'evo-512' in the modification pop-up box. When you click it, Cruise will take you to the web page 'http://xxx.xx.xx/yourproject/512'.
Notes: You can not define multiple tracking tools in one pipeline.
<stage>
The <stage> element specifies a set of jobs. Any job in a given stage failed means the stage failed. If a previous stage is followed by a stage with <approval>, the next stage will be triggered manually no matter what's the result of the previous stage.
Notes:There must be at least one job in stage.
Attributes
| Attribute | Required | Description |
|---|---|---|
| name | Yes | The name is used to identify a stage in the pipeline, so it has to be unique for that <pipeline>. The available characters in stage name are following: a-z, A-Z, 0-9, fullstop, underscore and hyphen. Spaces are not allowed. The name is case-insensitive in Cruise. |
<materials>
The <materials> element specifies the source of the pipeline changes. Generally this will be your codebase in your source control repository. Cruise will check modifications and check out your code by this material.
Notes:Currently Cruise only support multiple materials for Subversion material and dependency material within one pipeline. Cruise checks modifications every 1 minute. You can not currently specify the interval for checking modifications.
<filter>
The <filter> element is the container of ignore which specifies files in changesets would not trigger a pipeline. You can only define one filter under each SCM material.
<ignore>
The <ignore> element is used to specify a set of files, the changesets of that files will not trigger a pipeline.
Attributes
| Attribute | Required | Description |
|---|---|---|
| pattern | Yes | it defines a pattern(Ant-style) for the files. The changes of thoes files will not trigger the pipeline. the pattern should start from the root of the SCM repository, not the sandbox of pipeline. |
notes
- Can define multiple <ignore> under <filter>
- The pattern takes the root directory of the SCM repository as the root directory, not the sandbox in the agent side or the materials URL.
- The pipeline would be triggered anyway if the changeset include both of the ignored files and other codes.
- Those ignored files would check out with other codes together.
Examples:
<ignore pattern="doc/**/*.*" />Ignore everything under the folder 'doc'.
<ignore pattern="doc/*.*" />Ignore files under the folder 'doc', excluding those subfolder..
<ignore pattern="framework/helper/*.doc" />Ignore files that are under the directory '/framework/helper' and the file externtion is doc.
<ignore pattern="*.pdf" />Ignore files that are under the root directory of SCM repository and the file externtion is pdf.
<ignore pattern="**/helper/*.pdf" />Ignore all the files that is under any 'helper' folder and the file externtion is pdf.
<ignore pattern="helper/**/*.pdf" />Ignore all the files that are in the nested directory under folder 'helper' of the repository and the file externtion is pdf.
<svn>
The <svn> element specifies the location of your code base in Subversion repository.
Attributes
| Attribute | Required | Description |
|---|---|---|
| url | Yes | URL for the remote repository, like 'http://studios.thoughtworks.com/svn/myproject/trunk'. Cruise supports the following protocols for subversion: http, https, svn and svn+ssh, but does not support 'file:///'. |
| username | No | The user account for the remote repository. |
| password | No | The password for the specified user |
| checkexternals | No | default value is false, the value should be either one of [true, 1, false, 0]. 'true' or '1' means that the changes of externals will trigger the pipeline automatically. |
| dest | Yes (Only for multiple materials) | The directory under the sandbox of Cruise Agent, and it isn't allowed to start from '.'. Cruise will check out the source code into this directory. |
Notes:
If you are using https for svn repository, you have to go to the server and each agent, and as the user 'cruise', do a command "svn update" to store the certificates in the cache permanently.
Since 1.2, you can use multiple svn repositories in a pipeline, but you have to define dest for each repository.
Examples:
If Cruise Agent installed under /var/lib/cruise-agent on linux, and the configuration is following
<pipeline name="myproduct">
<materials>
<svn url="http://cruise.thoughtworks.com/framework" dest="framwork"/>
<svn url="http://cruise.thoughtworks.com/componentOne" dest="mycomponent"/>
<materials/>
......
<pipeline/>
Cruise Agent will check out source code from 'http://cruise.thoughtworks.com/framework' to '/var/lib/cruise-agent/pipelines/myproduct/framwork', and from 'http://cruise.thoughtworks.com/componentOne' to '/var/lib/cruise-agent/pipelines/myproduct/mycomponent'.
<hg>
The <hg> element specifies the location of your code base in a Mercural repository. Cruise supports two protocols for mercural: http and ssh.
Notes:
You must install Mercurial 1.0 or above on the Cruise Server and Cruise Agents for the jobs need Mercurial. Cruise does not Ship with Mercurial.
Attributes
| Attribute | Required | Description |
|---|---|---|
| url | Yes | URL to fetch source code from the Mercurial repository. If you specify the username and password for the Mercural repository, you have to put them into the url. |
<p4>
The <p4> element specifies the location of your code base in a Perforce repository.
Notes:
Cruise will use directory under pipelines/{pipelineName} in agent side as Perforce root directory of perforce client workspace.
Attributes
| Attribute | Required | Description |
|---|---|---|
| port | Yes | Perforce server connection to use (host:port). |
| username | No | Perforce username to use. |
| password | No | Password for the specified user. |
| useTickets | No | Set to true to work with perforce tickets. Cruise will do a p4 login using the supplied password before each command. We recommend that you make your user a part of a p4 group, and set the ticket timeout to unlimited as described here: http://www.perforce.com/perforce/doc.current/manuals/cmdref/login.html |
| view | Yes | Valid Perforce view. The view should be a sub-element of P4. |
Examples
<materials>
<p4 port="10.18.3.102:1666" username="userName" password="passwd">
<view><![CDATA[//depot/... //cruiseclient/...]]></view>
</p4>
</materials>
<git>
The <git> element specifies the location of your code base in a GIT repository. Cruise only supports remote repository.
Notes:
Currently Cruise just support the master brunch of GIT repository whihout username and password. And Cruise will use directory under pipelines/{pipelineName} in agent side as GIT root directory of the pipeline workspace.
Attributes
| Attribute | Required | Description |
|---|---|---|
| url | Yes | GIT URL for the repository. |
Notes:
You must install GIT 1.6.0.2 or above on the Cruise Server and Cruise Agents if you use http or https protocal.
Cruise test passed on GIT 1.6.0.2.
Examples are:
<materials>
<git url="git://127.0.0.1/precommit.git" />
</materials>
<materials>
< git url="http://ccegit:pst@cruiseserver.yourcompany.com/httpgit.git" / >
</materials>
<pipeline>
The <pipeline> element specifies that successful completion of a stage in another pipeline will trigger the current pipeline to start.
If there are multiple pipeline dependencies, then any one of them passing will trigger a new pipeline.
Attributes
| Attribute | Required | Description |
|---|---|---|
| pipelineName | Yes | The name of a pipeline that this pipeline depends on. |
| stageName | Yes | The name of a stage which will trigger this pipeline once it is successful. |
Notes:
The downstream pipeline wouldn't be triggered if there was no passed stage in the upstream pipeline.
Examples
Suppose there are four pipelines, and they are commonLib1, commonLib2, Server and Client. For example, the stage 'distStage' in commonLib1 pipeline can trigger the other two pipelines, and the stage 'pkgstage' in commonLib2 pipeline can trigger Server pipeline. The configuration would be:
<pipeline name="commonLib1">
...
<stage name="unittest">
...
</stage>
<stage name="distStage">
...
</stage>
<stage name="publishStage">
...
</stage>
</pipeline>
<pipeline name="commonLib1">
...
<stage name="unittest">
...
</stage>
<stage name="functionaltest">
...
</stage>
<stage name="pkgStage">
...
</stage>
</pipeline>
<pipeline name="Server">
<materials>
<pipeline pipelineName="commonLib1" stageName="distStage"/>
<pipeline pipelineName="commonLib2" stageName="pkgStage"/>
</materials>
...
</pipeline>
<pipeline name="Client">
<materials>
<pipeline pipelineName="commonLib1" stageName="distStage"/>
</materials>
...
</pipeline>
<jobs>
The <jobs> element specify the set of jobs for a stage.
Note:<jobs> can contain several <job> elements. These jobs can run in parallel on different <agents>.
<job>
A job is the basic unit of work. It is executed on an agent. A job can fetch artifacts from Cruise Server, execute tasks and publish artifacts back to Cruise Server.
A job can also be associated with a set of <resources> so that it can be executed on an agent with satisfying resources.
Attributes
| Attribute | Required | Description |
|---|---|---|
| name | Yes | The name of the job. It has to be unique within a <stage>. The name can contain: a-z, A-Z, 0-9, fullstop, underscore and hyphen only. Spaces are not allowed. Name is case-sensitive. However, it is adviced to use case-insensitive names for jobs within a stage. |
<resources>
<resources> specifies the resources needed for a job. A job can have zero or more resources.
If a job has no resources it can be built on any agent.
<resource>
A <resource> is a text tag that specifies a resource which a job requires to build. Agents which are tagged with at least the same resources are eligible to execute the job. Resource is case-insensitive.
Example:
<resources> <resource>jdk5</resource> <resource>tomcat5</resource> <resource>mercurial</resource> </resources>
<tasks>
<tasks> specifies the tasks (like <ant>, <rake> etc) that will run as part of a job.
There can be zero or more tasks. These tasks are executed in the order specified in the configuration file. If a task fails, the subsequent tasks are not run.
The following environment variables are set for all tasks:
| Variable | Description |
|---|---|
| CRUISE_SERVER_URL | The base URL for the server, including '/cruise'. For example: https://localhost:8154/cruise |
| CRUISE_PIPELINE_NAME | The name of the pipeline to which the job belongs to |
| CRUISE_PIPELINE_LABEL | The label of the pipeline to which the job belongs to |
| CRUISE_STAGE_NAME | The name of the stage to which the job belongs to |
| CRUISE_STAGE_COUNTER | The re-run counter of the stage to which the job belongs to |
| CRUISE_JOB_NAME | The name of the job that is being run |
| CRUISE_DEPENDENCY_LABEL_<upstream_pipeline_name>_<upstream_stage_name> |
The label of the upstream pipeline which triggered the pipeline to which the job belongs to. For example: 'CRUISE_DEPENDENCY_LABEL_framework_dev' is the environment variable where the name of the upstream pipeline is 'framework' and the upstream stage is 'dev'. Hyphen ('-') is an illegal character in an environment variable. So if a pipeline name or stage name contains '-', it will be converted into an underscore. For example, ‘pipeline-foo’ with stage ‘stage-foo’ becomes: CRUISE_DEPENDENCY_LABEL_pipeline_foo_stage_foo. |
<ant>
Specifies an Ant build to run. Ant is assumed to be present from the command line on the agent. Cruise depends on and uses JDK 1.6. If JDK 1.4 or 1.5 binaries are required by a build, it can be specified in the Ant javac task.
All paths specified must be relative to the working directory of the pipeline's materials.
Attributes
| Attribute | Required | Description |
|---|---|---|
| buildfile | No | Path to Ant build file. If not specified, the path defaults to 'build.xml'. The path cannot start from '.' |
| target | No | Ant target(s) to run. If not specified, the target defaults to 'default' |
| workingdir | No | The directory from where Ant is invoked |
Examples
-
Invoke Ant, specifying a set of targets to run:
<ant target="-Drun=all clean.ivy.localivy clean ft.long_running"/>
-
Invoke Ant in a specific working directory with a set of targets:
<ant workingdir="build" buildfile="mybuild.xml" target="-Drun=all clean.ivy.localivy clean ft.long_running"/>
<exec>
Runs a specified command. The build fails if the command cannot be run or if it returns an error.
All paths specified must be relative to the working directory of the pipeline's materials.
Attributes
| Attribute | Required | Description |
|---|---|---|
| command | Yes | The command or script to be executed, relative to the working directory |
| args | No | Set of arguments (as a single string) to be passed to the command or script. Note: Cruise does not support 'double quote in double quote' in an argument for this task |
| workingdir | No | The directory in which the script or command is to be executed |
Examples
-
Invoke ruby, specifying the working directory as workspace/codebase and executing the ruby script backup.rb.
<tasks> <exec command="/usr/local/bin/ruby" args="backup.rb" workingdir="workspace/codebase"/> </tasks>
<nant>
Specifies a NAnt build to be run. NAnt is assumed to be present from the command line on the agent.
All paths specified must be relative to the working directory of the pipeline's materials.
Attributes
| Attribute | Required | Description |
|---|---|---|
| buildfile | No | Path to NAnt build file. If not specified, the path defaults to 'default.build'. The path cannot start from '.' |
| target | No | NAnt target(s) to run. If not specified, defaults to the default target of the build file. |
| workingdir | No | The directory from where NAnt is invoked |
| nantpath | No | Path of the directory in which NAnt is installed. By default Cruise will assume that NAnt is in the system environment variable ${path}. If the path is specified, then it should be ensured that the path is the same in all agents which run the job. |
Examples
-
Invoke NAnt, specifying a set of targets to run:
<nant buildfile="myproject.build" target="smoke-test"/>
<rake>
Specifies a Rake build to be run. Ruby and Rake are assumed to be present from the command line on the agent.
All paths specified must be relative to the working directory of the pipeline's materials.
Attributes
| Attribute | Required | Description |
|---|---|---|
| buildfile | No | Path to Rake file. If not specified, the path defaults to 'rakefile'. The path cannot start from '.' |
| target | No | Rake target(s) to run. If not specified, defaultd to the default target of the build file |
| workingdir | No | The directory from where Rake is invoked |
<fetchartifact>
Fetch artifacts from previous stages in the same pipeline or stages of upstream pipelines that this pipeline depends on.
All paths specified are relative to the working directory of the pipeline's materials.
Attributes
| Attribute | Required | Description |
|---|---|---|
| pipeline | No | The name of upstream pipeline on which the pipeline of the job depends on. The pipeline should be added as a dependency under <materials>. |
| stage | Yes | The name of the stage to fetch artifacts from |
| job | Yes | The name of the job to fetch artifacts from |
| srcdir | No | The path of the artifact directory of a specific job. The path cannot start from '.' Note: If the directory does not exist, the job is failed |
| srcfile | No | The path of the artifact file of a specific job. Note: If the file does not exist, the job will fail. Cruise will not fetch the artifact again if it has not changed. The directory path is relative to the pipeline working directory. |
| dest | No | The path of the directory where the artifact is fetched to. The directory is overwritten if it already exists. The directory path is relative to the pipeline working directory. |
Note: Only one of 'srcdir' and 'srcfile' can be present.
Example:
-
Fetch the artifacts at the directory 'pkg' from the previous stage in the same pipeline and put it under the directory 'lib'
<pipelines> <pipeline name="cruise"> <stage name="dev"> <jobs> <job name="unit"> <artifacts> <artifact src="target/deployable.jar" dest="pkg"/> </artifacts> </job> </jobs> </stage> <stage name="ft"> <jobs> <job name="functional"> <tasks> <fetchartifact stage="dev" job="unit" srcdir="pkg" dest="lib"/> </tasks> </job> </jobs> </stage> </pipeline> </pipelines> -
Fetch a single artifact from a stage in the upstream pipeline 'framework' and put it under the directory 'lib'
<pipeline name="cruise"> <materials> <pipeline name="framework" stage="ft"/> </materials> <stage name="dev"> <jobs> <job name="unit"> <tasks> <fetchartifact pipeline="framework" stage="dev" job="unit" srcfile="pkg/deployable.jar" dest="lib" /> </tasks> </job> </jobs> </stage> </pipeline>
<artifacts>
<artifacts> specifies what files the agent will publish to the server.
<artifact>
Publish build artifacts to the artifact repository for the job.
Attributes
| Attribute | Required | Description |
|---|---|---|
| src | Yes | The file or folder to publish to the server. Relative to the working directory of the job, and it isn't allowed to start from '.' |
| dest | No | The destination is relative to the artifacts folder of current instance on the server side, and it
isn't allowed to start from '.'. If it is not specified, the artifact will be stored in the root of the artifacts directory. |
<test>
The src attribute should point towards a folder that contains the test output files. Cruise will use these to generate a test report. Test information is placed in the Failures and Test sub-tabs. Test results from multiple jobs are aggregated on the stage detail pages. This allows you to see the results of tests from both functional and unit tests even if they are run in different jobs.
Attributes
| Attribute | Required | Description |
|---|---|---|
| src | Yes | Specify the directory into which the test output of the job will be put on agent side. This is relative to the job's working directory, and it isn't allowed to start from '.' |
| dest | No | The path in the artifacts repository where the reports will be placed, and it isn't allowed to start from '.'. |
<tabs>
The <tabs> element allows you to add tabs to the Job Details page. You can put any artifact into a tab. For example, if your coverage tool produces an html report, you can easily place that report into a tab.
<tab>
Define a tab specific name and and artifact to show.
Attributes
| Attribute | Required | Description |
|---|---|---|
| name | Yes | The name of the sub-tab. If should be unique in that job. |
| path | Yes | The relative path of a file in the artifact repository of the job. Absolute paths are invalid. |
Example:
Given some coverage infomation in 'target/Jcoverage' folder on the agent side, We configure a tab to show the coverage information by specifying a tab with the index.html file.
<artifacts>
<artifact src="target/jcoverage" dest="Jcoverage">
</artifacts>
<tabs>
<tab name="coverage" path="Jcoverage/index.html">
</tabs>
<properties>
The <properties> element allows you to create properties of the build from XML files or artifacts created during your build.
<property>
Define a Property based on the contents of an XML file.
Attributes
| Attribute | Required | Description |
|---|---|---|
| name | Yes | The name of the property. It has to be unique within a <job>. The name can contain: a-z, A-Z, 0-9, fullstop, underscore and hyphen only. Spaces are not allowed. Name is case-sensitive. |
| src | Yes | The xml file containing the data that you want to use to create the property, and it isn't allowed
to start from '.' Properties are set on the Agent at the end of the build and does not need to be an artifact that will be uploaded to the server. |
| xpath | Yes | The XPath that will be used to create the property. |
Reference
<approval>
Specifies how a stage should be triggered. An <approval> of type 'manual' can be used to stop a pipeline execution at the start of a stage and can only be resumed when it is manually approved on the pipeline activity page or through RESTful url.
Attributes
| Attribute | Required | Description |
|---|---|---|
| type | No | Either 'manual' or 'success'. 'manual' means the stage needs to be approved manually. 'success' means the stage will be automatically triggered when the previous stage passes. |
- <approval> must be the first sub-element of <stage>.
- If an approval is not specified or does not specify any type then the behavior is same as 'success' i.e. the stage will be automatically triggered.
<auth>
You can use <auth> under an <approval> with a 'manual' type to specify who can approve this stage. There are two sub-elements: <user> and <role>.
Examples
<approval type="manual">
<auth>
<user>lqiao</user>
<role>cruise_admins</role>
</auth>
</approval>
Notes:
- You can not specify <auth> in <appoval> without type="manual".
<agents>
The <agents> element specifies the set of agents known by the server.
Notes:Do not change it manually. You can manage these through the Agents tab.
<agent>
An approved agent. Before it is approved, the agent is displayed on the top of the agent tab with a grey bar.
Attributes
| Attribute | Required | Description |
|---|---|---|
| hostname | Yes | Hostname for the agent |
| ipaddress | Yes | IP for the agent. |
| uuid | Yes | Identifier for the agent. It is created by Cruise automatically. |
| isDenied | No | The values should be either one of [true, 1, false, 0]. 'true' or '1' means that the agent is denied. Cruise doesn't assign jobs to a denied agent. |
Notes:
Cruise uses the agent's hostname as its identification.
A local agent will be approved automatically.
<resources>
<resources> descibes the resources available on a particular agent.
Note:An agent without any resources will build any jobs that don't specify resources. Refer to the <resources> of <job>.
<resource>
resources names can contain the following characters: a-z, A-Z, 0-9, fullstop, underscore and hyphen. Spaces are not allowed.
Examples
<agents>
<agent hostname="agent01" ipaddress="192.168.0.1" uuid="94fcb7ad-8b97-4078-b5f6-3c7436d6a390">
<resources>
<resource>java</resource>
<resource>linux</resource>
</resources>
</agent>
</agents>