This article needs significant rework.
In this example, the version is automatically incremented by placing a variable in the pom.xml file
<?xml version="1.0" encoding="UTF-8"?>
..
<artifactId>springboot</artifactId>
<groupId>io.cdaf</groupId>
<name>Spring Boot Data REST Sample</name>
<description>Spring Boot Data REST Sample</description>
<version>0.2.${build.number}</version>
In the build task, the build number is supplied as a maven parameter
mvn --batch-mode --file springboot/pom.xml package -D"build.number=${BUILDNUMBER}"
The resulting artefact is in a subdirectory, buy using the -flat parameter in storeFor the artefact will be placed in the root of release package.
springboot/target/springboot.war -flat
In this example, the decreasingly used remote task is implemented to deploy to a remote server, in this case, both pre-production and production are hosted on the same server. Note that there is also a local context, this is used to test the deployment.
context target deployHost deployUser deployLand runtime
remote staging perimeter.example.com tomcat /opt/packages/$DEPLOY_TARGET /opt/tomcat/webapps/pp.war
local staging http://perimeter.example.com/pp
remote production rails.hdc.company tomcat /opt/packages/$DEPLOY_TARGET /opt/tomcat/webapps/pr.war
local production http://perimeter.example.com/pr
Two deployment tasks are needed, first, tasksRunRemote.tsk will deploy the build artefact, using the verbose copy operation.
VECOPY springboot.war ${runtime}
Once deployed, tasksRunLocal.tsk will test the deployment, using the CDAF helper to cater for delays in WAR file deployment.
EXERTY "curl --silent $deployHost"