13.7.3. Building Applications with Jenkins

Building applications with Jenkins uses dedicated application space, which can be larger than the application runtime space. The Jenkins online build system monitors applications that have an embedded Jenkins Client, and automatically rebuilds and deploys those applications whenever changes to the Git repository are pushed to the remote server without any further interaction. The existing application is not affected until a new, successful build has been created. If the build fails, the existing application continues to run. However, note that a failure in the deployment process (deploy - start - post_deploy) could leave the application partially deployed or inaccessible.
The actual build and deployment process that Jenkins executes involves the following steps:
  1. The git push command is executed, and Jenkins is notified that a new push is ready.
  2. A dedicated Jenkins slave (a builder) is created. The rhc apps command shows slave information. The application name is the same as that of the originating application, but with a .bldr suffix.


    The first 28 characters of the application name must be unique to avoid build issues that are caused when builders are shared across applications.
  3. Jenkins runs the build.
  4. Content from the originating application is downloaded to the builder application using git (for source code) and rsync (for existing libraries).
  5. ci_build.sh is called from the Jenkins shell. This sets up the builder application for the Jenkins environment and performs some built-in bundling steps (PHP pear processing, Python virtual environment, etc).
  6. .openshift/action_hooks/build is executed on the Jenkins builder.
  7. Any additional desired steps are executed from the Jenkins shell (Maven build, Gem install, test cases, etc).
  8. Jenkins stops the currently running application, and runs rsync to synchronize all new content over to the originating application.
  9. .openshift/action_hooks/deploy is executed on the originating application.
  10. Jenkins starts the originating application, and .openshift/action_hooks/post_deploy is executed on this application.
  11. Jenkins archives all build artifacts for later reference.
  12. After 15 minutes of idle time, the "build app" will be destroyed and will no longer appear in the output of the rhc apps command. The build artifacts, however, will still exist in Jenkins and can be viewed there.
The build job can be monitored using the Jenkins interface. The interface provides an extensive range of information about the current build, build history, artifacts, as well as plug-ins to graph, track, run tests, and perform other operations.
Log all errors related to Jenkins, such as DNS timeout and builder configuration, with the following command, specifying the name of the Jenkins application if it was changed:
$ rhc tail jenkins
Error logs for applications, such as compilation or test failures, are available from the Jenkins web interface under the corresponding build history. Deployment related errors are logged in the application's log files, and can be viewed with the following command:
$ rhc tail App_Name Building Custom Applications

Build custom applications, or applications that have no upstream repositories, directly from the Jenkins web interface instead of using the git push command.
Click on the icon of the application from the Jenkins web interface, located on the right side, to build it.
View the status of the build process in the web interface under the Build Executor Status section.