Schedule Parameters.

Schedule Parameters.
	Chapter 14. Creating Build Schedule(s) for the Project

Name. Provide a name for this schedule. This name will be used to identify this schedule, and cannot be changed later. Keep in mind that schedule name is used as subdirectory of the project publish directory.

Description. Provide a description for this schedule.

Next build version. Specify the string for the next build version, keep in mind the name will be used as a subdirectory in the schedule's publish directory. The version string is incremented by Luntbuild as follows:

luntbuild-1.0 will be increased to luntbuild-1.1

luntbuild-1.2.9 will be increased to luntbuild-1.2.10

luntbuild-1.5(1000) will be increased to luntbuild-1.5(1001)

In general, the last number in the "Next build version" will be incremented with every build. For example "luntbuild-1.2.0" will increase to "luntbuild-1.2.3" after three builds. However, if there are OGNL expressions (encapsulated within ${...}) embedded in, the last number will not be increased automatically. Luntbuild will evaluate every embedded OGNL expression to get the actual version string for the specific build. When performing the evaluation, current Schedule object will be used as the OGNL root object. Here are some examples of using OGNL expression to achieve various versioning strategy:

Scenario 1:

Put current date and iteration of this date as the part of the build version.

Define "next build version" of every schedule to be:

    foo-${#currentDay=system.(year+"-"+month+"-"+dayOfMonth), \
    #lastDay=project.var["day"].setValue(#currentDay), \
    #dayIterator=project.var["dayIterator"].intValue, \
    project.var["dayIterator"]. setIntValue(#currentDay==#lastDay?#dayIterator+1:1), \
    #currentDay}.${project.var["dayIterator"]}

The actual version string for a build will include the build date and iterations for that date.

Scenario 2:

"test" and "release" schedule shares and increases the same version string, while "continuous integration" schedule uses another independent version.

Both "test" and "release" schedule set "next build version" to be:

    foo-${project.var["majorVersionPart"]}.\
    ${project.var["minorVersionPart"].increaseAsInt()}

For "continuous integration" schedule, set "next build version" to be:

    foo-1

Scenario3:

"release" schedule increases release part of the version, while "nightly" schedule increases iteration part of the version. When release part of the version changes, iteration part should be reset to 1.

Define the following variables for the project:

fixPart=foo-1.1

releasePart=1

iterationPart=0

Define "next build version" of "nightly" schedule as:

${project.var["fixPart"]}.${project.var["releasePart"]}-build-${project.var["iterationPart"].increaseAsInt()}

Define "next build version" of "release" schedule as:

${project.var["fixPart"]}.${project.var["iterationPart"].setValue(1), project.var["releasePart"].(increaseAsInt(), value)}

This way, builds in "release" schedule will get versions like: foo-1.1.1, foo-1.1.2, foo-1.1.3, ..., and builds in "nightly" schedule will get versions like: foo-1.1.1 build 1, foo-1.1.1 build 2, foo-1.1.1 build3, ...., foo-1.1.2 build 1, foo-1.1.2 build2, ...

	Note
	After the evaluation of an OGNL expression, Luntbuild will substitute all "." characters in the version string with "_", and all blank characters with "-". This string is then used as the label which will be applied to source code in the Version Control System for the particular build. For example, if the build's version is "v1.0 build256", source code for this build will be labeled as "v1_0-build256".

	Note
	Luntbuild labels the source code based on the version number. If there are multiple projects, and/or multiple builds configured in Luntbuild, you should make sure there are no duplicate version strings in Luntbuild. For example, if you configure build1 with next build version as "v1.0", and configure build2 with next build version as "v1.5" and both of these builds contain the same module and they are using the same Version Control System, then after five builds or more, version number of build1 will have duplicate version number(s) with the early builds of build2. The best practice is to name the version number for each build with project/build prefix, such as "luntbuild-dev-0.9.2".

Work directory. Work directory for the schedule. Non-absolute path will be assumed to be relative to Luntbuild's top level work directory. If left empty, <global_work_dir>/<project_name> will be assumed, where <global_work_dir> stands for Luntbuild's top level work directory, and <project_name> stands for project name of this schedule. It is possible to use the same work directory for multiple schedules of the same project. See build work directory.

Trigger type. Select the trigger type for this schedule. Value "manual" means build of this schedule can only be triggered manually. Value "simple" can be used to configure a periodic trigger (repeated every N minutes). Value "cron" can be used to configure a cron-like trigger. Refer to http://www.opensymphony.com/quartz/ for details about how to configure cron trigger.

Cron expression. Set the cron expression for this schedule, the format is <seconds> <minutes> <hours> <day-of-month> <month> <day-of-week>. For example 0 1 * * ? means 1:00am every day. For details of the format, refer to Cron triggers tutorial.

Repeat interval (minutes). Set the repeat interval for this schedule in minutes.

Build necessary condition. The "Build necessary condition" is optional. If left empty, the "vcsModified or dependencyNewer" value is assumed. This property is used by Luntbuild to determine, if the current build is necessary when the build strategy of the build schedule is set to "build when necessary". The "Build necessary condition" is an OGNL expression. When this expression evaluates to true, the build is considered necessary. Root object used for OGNL expression evaluation here is current Schedule object. Here are some examples to show the format of this OGNL expression:

vcsModified - this expression will evaluate to true if the repository content of the current build changes
dependencyNewer - this expression will evaluate to true if new builds are generated in one of the dependent schedule
dependencySuccessful - this expression will evaluate to true if latest builds in all dependent schedules are successful
always - this expression will always evaluate to true to force the build
never - this expression will always evaluate to false to pause the build
alwaysIfFailed - this expression will always evaluate to true if last build has failed, and will have the value of "vcsModified or dependencyNewer" if last build is successful.
project["testcvs"].vcsModified - this expression will evaluate to true if the repository content of the "testcvs" project changes.
system.execute("/path/to/command.sh") == 0 - this expression will evaluate to true if the return code of the execution of the specified command is 0.
Note
Special characters such as '\', '"', should be escaped with '\', just like in Java strings.

	Note
Special characters such as '\', '"', should be escaped with '\', just like in Java strings.

The above expressions can be prefixed with '!' to inverse the value, for example !modified will be true when there are no modifications in the repository of the current project.

The above expressions can be joined with "and", and "or". For example, the expression: modified or execute("/path/to/command.sh")==0 will be true, if repository content of the current project changes, or execution of the specified command returns 0.

The above expressions can be prefixed with '!' to negate the value, for example "!modified" will evaluate to true when there are no modifications in the repository of current view. The above expressions can also be joined with "and", "or". For example, the expression modified or execute("/path/to/command.sh")==0 will evaluate to true if the repository content of the current view changes, or execution of the specified command returns 0.

Please go to http://www.ognl.org to learn more about general grammar of an OGNL expression.

Associated builders. Select builders associated with the current schedule. They will be executed one by one in the selected order.

Associated post-builders. Select post-builders associated with the current schedule. Associated post-builders will be executed after all associated builders, if the condition indicated by "post-build strategy" is met.

Build type. Select the build type for this schedule, clean build can be more reliable, but can be slower. Incremental build can be quicker, but less reliable. We suggest that all important build schedules such as nightly or release should use clean build, and very frequent build schedules such as hourly development build, can be incremental.

	Note
	This setting will only take effect when the build is not triggered manually. For manual builds, this value will be shown as the default value, when the schedule is being manually build.

Post-build strategy. Select the post-build strategy for this schedule. There are following strategies:

do not post-build: Do not execute post-build script after the build.
post-build when success: Execute post-build script only when the build was successful.
post-build when failed: Execute post-build script only when the build has failed.
post-build always: Always execute post-build script after the build.

	Note
	This setting will only take effect when the build is not triggered manually. For manual builds, this value will be shown as the default value when the schedule is being build manually.

Label strategy. Choose the label strategy for this schedule. There are following strategies:

label successful builds: Label the repository only for the successful builds.
do not label: Do not label the repository after the build.
label always: Always label the repository after the build.

	Note
	If the build is not labeled when it is initially built, it will not be rebuildable later.

	Note
	This setting will only take effect when the build is not triggered manually. For manual builds, this value will be shown as the default value when the schedule is being build manually.

Notify strategy. Choose the notify strategy for this schedule. There are following strategies:

notify when status changed: Send notification when status of the current build changes against the last build. That is, notification will be sent when the current build succeeds and the last build failed, or the current build fails and the last build succeeded.
notify when failed: Send notification only when the build failed.
notify when success: Send notification only when the build succeeded.
do not notify: Do not send notification after the build.
notify always: Always send notification after the build.

	Note
	This setting will only take effect when the build is not triggered manually. For manual builds, this value will be shown as the default value when the schedule is being build manually.

Dependent schedules. Select the schedules dependent on the current schedule. If scheduleA depends on scheduleB, Luntbuild will trigger the build of scheduleB before triggering the build in scheduleA. Schedule dependency might be used to define project dependencies.

Dependency triggering strategy. Choose the dependency triggering strategy defining when the current schedule is triggered. Following trigger strategies are available:

schedules this schedule depends on: Trigger schedules the current schedule depends on. Triggering of these schedules will happen before the current schedule is triggered. For example, if the current schedule uses several components built in other schedules, you can use this strategy to make sure that all components used by this schedule are up to date.
schedules that depends on this schedule: Trigger schedules that depends on the current schedule. Triggering of these schedules will happen after the current schedule is triggered. For example, if the current schedule builds a component that is used by other schedules, you can use this strategy to make sure that all components are up to date before starting the schedules that use this component.
all dependent schedules: This is the combination of the above two strategies, that is, it triggers the schedules current schedule depends on before actually triggering current schedule, and then it triggers the schedules that depends on the current schedule after triggering the current schedule.
do not trigger any dependent schedules: Do not trigger neither the schedules the current schedule depends on, nor the schedules that depends on the current schedule.

	Note
	This setting will only take effect when the build is not triggered manually. For manual builds, this value will be shown as the default value when the schedule is being build manually.

Build cleanup strategy. Select the build cleanup strategy for this schedule.

do not cleanup builds automatically: Builds can be deleted only manually.

keep builds by day: Keep builds for specified number of days.

keep builds by count: Keep specified number of builds.

	Note
	If a build for the given project is currently running and a new build for the same project starts (either automatically or manually), the build is placed into the pending builds queue for the given schedule. A queue of pending builds is displayed on the project's Schedule tab page.


Chapter 14. Creating Build Schedule(s) for the Project		Chapter 15. Using Notification Templates