Managing Project Jobs and Builds in Oracle Developer Cloud Service

Oracle Developer Cloud Service includes continuous integration services based on Hudson to build project source files.

Topics

About the Build Page

The Build page, also called as the Jobs Overview page, displays information about all build jobs and provides links to configure and manage them.

About Builds

Oracle Developer Cloud Service runs builds and jobs on an Hudson based build executor. For more information about Hudson, see http://eclipse.org/hudson. You can also read the Hudson book at http://wiki.eclipse.org/The_Hudson_Book and the Hudson documentation at http://wiki.eclipse.org/Hudson-ci/documentation.

Tip:

Oracle Developer Cloud Service manages the installation, configuration, and management of Hudson. You may ignore the first few chapters of the Hudson book, which focus on installation and configuration.

If you have used Hudson before, note that Hudson master capabilities (such as installing the Hudson plugin, or starting or stopping the Hudson server) are not available in Oracle Developer Cloud Service.

Also see Managing Project Jobs and Builds in Oracle Developer Cloud Service.

What You Can Do from the Builds Page

See Actions you can perform on the Builds page.

What You See on the Builds Page

The following table highlights what you see on the Jobs Overview page.

Element Description

Build Queue

Displays all jobs in the queue.

To stop a build in the queue, click the X icon.

View Build History

Displays the history of all builds of the project.

In the table, click the job name to view its details. Click the build number to view the build details. Click the Console icon to view the console output of the build.

Job Statistics

Displays the job statistics in a pie chart format.

New Job

Creates a build job. See Creating a Job.

All Jobs/All Successful Jobs/All Failed Jobs/All Unstable Jobs

Click the toggle button to filter the jobs list in the jobs table.

By default, the jobs table lists all jobs.

Jobs table

Lists jobs matching the filter criteria and displays information in the following columns:

  • Status: Indicates the status of the last job build.

  • Weather: Indicates the stability of the job.

  • Job: Displays the name of the job. Click the link to open the job details page.

  • Last Success: Displays the date and time stamp of the last successful build.

  • Last Failure: Displays the date and time stamp of the last build failure.

  • Duration: Displays the duration of the last build.

  • Actions: Click Console output to open the job console of the last build. Click Last Build to open the details page of the last build. Click Build Now to run a build.

Creating a Job

To run builds and generate artifacts that you can deploy, you must create a job. You can create a job from the Build page.

To create a job:
  1. In the navigation bar, click Build.
  2. Click New Job.
  3. In the New Job dialog, enter a unique job name in Job Name.
  4. Select one of the following job types:
    • Create a free-style job: Creates a blank job where you must configure parameters to run a build.

    • Copy existing job: Select the job whose parameters you want to copy to the new job. After the job is created, you can then change the parameters of the new job.

      By default, the new job is disabled to prevent it from running any scheduled build while you are configuring the job’s copied parameters. To run builds of the copied job, you must enable it manually before saving.

  5. Click Save.
  6. In the Configure Build Job page, specify the configuration options and click Save. For more information about the configuration options, see Configuring a Job.

Viewing Job Details

Click the job name in the Jobs Overview page to view its details.

To view details of a job:

  1. In the navigation bar, click Build.

  2. In the Jobs table, click the job name link.

The following graphic shows the job details page of the TestJob1 job.

The following table highlights what you can do from the job’s details page.

Element Description

Description

Displays the job's description.

Permalinks

Displays the permanent links of the following job build:

  • Last: Opens the page of the last build

  • Successful: Opens the page of the last successful build

  • Failed: Opens the page of the last failed build

  • Completed: Opens the page of the last completed build

  • Unsuccessful: Opens the page of the last unsuccessful build

  • Stable: Opens the page of the last successful build that passed all its tests

  • Unstable: Opens the page of the last successful build that failed its tests

Notifications

If necessary, click the On toggle button to enable build notifications for all subscribed users. The email notifications are enabled by default when a job is created.

To subscribe yourself to the build email notifications of the job, click the CC Me icon and configure the build events in the CC Me dialog. For more information, see Subscribing to a Job’s Build Email Notifications.

Click the Off toggle button to disable build notifications for all subscribed users.

Artifacts of the Last Successful Build

Displays the download links of artifacts from the last successful build.

Build History

Displays the status of the running builds, and completed job builds in descending order (recent first) along with their build numbers, date and time, and a link to the console output of the build.

Click the build number link to open the build's status page. For more information, see Viewing Build Details.

If a running build is stuck in the Queued status for a long time, mouse over the Queued status to see a message about the problem.

Build Trend

Displays a graphical representation of the build time trend.

Test Result Trend

Displays a graphical representation of the JUnit tests trend. The graph indicates the number of failed, skipped and passed tests out of the total number of tests per build.

Click the graph buttons Vertical, Horizontal, Unstack, Stack to change the graph.

Build Now

Run the job.

When a build runs, the message New build Queued appears in Build History indicating that it is waiting for the next available executor to run the job. When it gets an executor, the Queued status is replaced by a status bar, and the build title appears in the Build History panel.

To cancel the build, click the Cancel icon adjacent to the progress bar.

Configure

Configure the job. For more information about available configuration options, see Configuring a Job.

Enable or Disable

Enable or disable the job.

If you created the job as a copy of an existing job, it is disabled by default. You must enable it to run builds.

Delete

Delete the job.

Latest Console

View the console output of the latest build.

Changes

View recent changes made to the source code that triggered the build.

The Changes page displays the files that were edited or added in the latest build of the selected job. You can also view the console output and Git build data from the Changes page.

Latest Test Results

View the latest JUnit test results of the latest build.

See Viewing a Build’s Test Results.

Git Logs

View the Git polling log of the latest build.

See Viewing a Build’s Git Polling Log.

Audit

View the Audit log of user actions.

See Viewing a Job’s User Action History.

Viewing Project’s Build History

You can use the Build History page to view the builds of all jobs of the project.

To view build history:
  1. In the navigation bar, click Build.
  2. In the Build Queue box, click the View Build History link.
You can view the following information in the Build History table.
Column Description

Status

Indicates the build’s status.

Build

Indicates the build number.

Click the build number link to open the build details page. See Viewing Build Details.

Job

Indicates the job name.

Click the job name link to open the job details page. See Viewing Job Details.

Time

Indicates the date-time stamp when the build ran.

Duration

Indicates the build’s duration.

Console

Click the Console icon to open the build’s console and view the console output.

Configuring a Job

From the Configure Build Job page, you can configure or edit a job so that when the job is built, it will perform the specified tasks. The tasks may include enabling and disabling builds, discarding old builds, configuring parameters for the build, and configuring Git repositories for the builds.

The Configure Build page is categorized into various tabs for the configuration settings of the job and its builds.

Tab Description

Main

Configure basic settings, such as name and description, of the job.

Build Parameters

Configure build parameters such as boolean value, file, run, choice, string, and password build parameters. See Configuring Build Parameters.

Source Control

Specify Git options for configuring repositories and branches, and for adding advanced Git options. See Configuring the Source Code Management System for Builds.

Triggers

Configure the options that will trigger the build. See Configuring Build Triggers.

Environment

Configure options for the X virtual frame buffer (Xvfb). See Configuring the Build Environment.

Build Steps

Configure the build steps that need to occur during the build. You can specify shell commands and invoke Ant, Maven 2 or Maven 3 commands, Gradle plugin, and Node.js plugin. See Configuring Build Steps.

Post Build

Select and configure actions that you want the system to perform after the build completes. These actions include building other jobs, archiving artifacts, publishing javadoc, recording fingerprints of files and artifacts, and providing notification when Maven dependencies have been updated by Maven 3 integration. See Configuring Post Build Actions.

Advanced

Specify advanced job options such as the quiet period and the retry count. See Setting Advanced Options for the Job.

Configure Basic Settings of a Job

To configure the basic settings of a job:

  1. In the navigation bar, click Build.

  2. In the Jobs table, click the job name link.

  3. Click Configure.

  4. To configure basic properties, click the Main tab if it is not already selected

    The following table highlights the elements of the Main tab of the Configure Build Job page:

    Element Description

    Name

    Edit the name of the job.

    Description

    Edit the description of the job.

    JDK

    Specify the version of the Java Development Kit. The specified version will be used for running builds.

    The Default value is set to the default JDK version set in the Oracle Developer Cloud Service build executor.

    Disable Build

    Select the check box to disable job builds. To enable job builds, deselect the check box.

    If you created the job as a copy of an existing job, it is disabled by default. You must enable it to run builds.

    Execute concurrent builds if necessary

    Select the check box to perform concurrent builds, if necessary.

    Discard old builds

    Select the check box to discard old builds. You can specify how many days you want to retain builds and artifacts. See Configuring Options for Discarding Old Builds and Artifacts.

  5. Click Save.

Configuring Options for Discarding Old Builds and Artifacts

Select the Discard Old Builds check box in the Configure Build Job page to allow the build system to discards old builds and artifacts each time a job is built.

To discard old builds:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Select the Main tab.

  3. Select the Discard Old Builds check box.

The following table highlights what you can configure after selecting the Discard Old Builds check box.

Element Description

Days to keep builds

Specify the number of days to retain builds. Enter a number greater than 0. All builds older than this number of days will be discarded. If left blank, any builds not discarded by setting Number of builds to keep will be kept.

Number of builds to keep

Specify the number of builds to retain. Enter a number greater than 0. If left blank, all builds will be kept. If the build is broken, the last working build will be kept.

Days to keep artifacts

Specify the number of days to retain the artifacts created by the build. Enter a number greater than 0. All artifacts older than this number of days will be discarded. If left blank, any artifacts for existing builds other than those discarded by setting Number of builds with artifacts to keep will be retained.

Number of builds with artifacts to keep

Specify the number of builds with artifacts to retain. Enter a number greater than 0. If left blank, all artifacts for existing builds will be retained.

Configuring Build Parameters

Select the This build is parameterized check box to add and configure build parameters.

The following table highlights the elements of the Build Parameters tab of the Configure Build Job page:

Element Description

This build is parameterized

Select the check box to add the build parameters in the Configure Build Parameters field.

Enable merge request parameters

Enable merge requests to run builds of this job from the Linked Builds tab of the merge request.

See Enabling Merge Request Parameters.

Configure Build Parameters

Select the build parameter from the Add Parameter drop-down list.

You can add the following kinds of build parameters to your build:

When you run a build after setting build parameters, a form is displayed before the build is started, allowing you to set a value or change the default value of parameters.

Adding a Boolean Parameter

A boolean parameter is a parameter that can be used during a build, either as an environment variable, or through variable substitution in some other parts of the configuration. Its value could be true or false.

To add a boolean parameter:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Select the Build Parameters tab.

  3. Select the This build is parameterized check box.

  4. Click Add Parameter and select Boolean Value.

The following table highlights what options you can set for a boolean parameter value.

Element Description

Name

Enter the name of the parameter. This is a required field.

Default Value

Select the check box to specify true as the default value of the field.

Description

Enter a description of the parameter.

Adding a File Parameter

A file parameter is a parameter that causes the build system to accept a file submission from a browser as a build parameter. The uploaded file will be placed at the specified location in the workspace and your build can then access and use it.

To add a file parameter:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Parameters tab.

  3. Select the This build is parameterized check box.

  4. Click Add Parameter and select File Parameter.

The following table highlights the options you can set for a file parameter.

Element Description

File location

Specify the location, relative to the workspace, where the uploaded file will be placed (for example, jaxb-ri/data.zip). This is a required field.

Description

Enter a description of the parameter.

Adding a file parameter useful for many situations, such as:

  • Letting users run tests on the artifacts they built

  • Automating the upload, the release, or the deployment process by allowing the user to place the file in a specified location

  • Processing data by uploading a dataset

If no file is submitted and if no file is already present at the specified location in the workspace, then nothing happens. If there's already a file present in the workspace, then this file will be kept as is.

Adding a Run Parameter

A run parameter is a parameter that allows users to trigger a single build of a certain job. The absolute URL of this build will be exposed as an environment variable, or through variable substitution in some other parts of the configuration.

To add a run parameter:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Parameters tab.

  3. Select the This build is parameterized check box.

  4. Click Add Parameter and select Run Parameter.

The following table highlights what options you can set for a run parameter.

Element Description

Name

Enter the name of the parameter that will be exposed as an environment variable. This is a required field.

Job

Select the job from which the user can pick runs. The last run will be the default. This is a required field.

Description

Enter a description of the parameter.

Adding a Choice Parameter

A choice parameter is a string parameter that users can select from a list. This parameter can be used during a build, either as an environment variable, or through variable substitution in some other parts of the configuration.

To add a choice parameter:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Parameters tab.

  3. Select the This build is parameterized check box.

  4. Click Add Parameter and select Choice.

The following table highlights the options you can set for a choice parameter.

Element Description

Name

Enter the name of the parameter that will be exposed to the build as an environment variable. This is a required field.

Choices

Enter the list of potential choices, one per line. The value on the first line will be the default. This is a required field.

Description

Enter a description of the parameter.

Adding a String Parameter

A string parameter is a text parameter where users can enter a string value, which can be used during a build. The parameter can be used either as an environment variable or through variable substitution in some other parts of the configuration.

To add a string parameter:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Parameters tab.

  3. Select the This build is parameterized check box.

  4. Click Add Parameter and select String Parameter.

The following table highlights what options you can set for a string parameter.

Element Description

Name

Enter the name of the parameter that will be exposed to the build as an environment variable. This is a required field.

Default Value

Specify the default value of the field. This is a required field.

Description

Enter a description of the parameter.

Adding a Password Parameter

A password parameter is a text parameter, where users can enter a string value, which you can use during a build. The value can be specified either as an environment variable or through variable substitution in some other parts of the configuration.

To add a password parameter:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Parameters tab.

  3. Select the This build is parameterized check box.

  4. Click Add Parameter and select Password Parameter.

The following table highlights what options you can set for a password parameter.

Element Description

Name

Enter the name of the parameter that will be exposed to the build as an environment variable. This is a required field.

Default Value

Specify the default value of the field. This is a required field.

Description

Enter a description of the parameter.

Enabling Merge Request Parameters

If you want to link the job to a merge request, you must enable the job to accept merge request parameters.

To enable merge request parameters:
  1. Open the Configure Build Job page of the job.
  2. Click the Build Parameters tab.
  3. Select the This build is parameterized check box.
  4. Select the Enable merge requests parameters check box.
When the Enable merge requests parameters check box is selected, the job configuration creates three String parameters GIT_REPO_URL, GIT_REPO_BRANCH, and MERGE_REQ_ID to accept the Git repository URL, the Git repository branch name, and the merge request ID as input from the merge request respectively.

Configuring the Source Code Management System for Builds

Use the Source Control tab in the Configure Build Job page to configure repositories, branches, and advanced Git settings.

To configure Git source control:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Source Control tab.

  3. Select the Git option.

In the Repositories section, click Add to select the Git repository URL. To remove the repository, click the Remove icon.

The following table highlights what you can set in the Repositories section when Git is selected as the source repository.

Element Description

URL

Select or enter the repository URL from the list to track. This is a required field.

Advanced Repository Settings

Expand the Advanced Repository Settings subsection to configure the advanced options for the selected Git repository.

The following table highlights what you can set in the Advanced Repository Settings subsection.

Element Description

Name

Enter the name of the repository. Leave the field empty to use the default name of the repository.

Reference spec

Specify the reference specification of the repository. This is an optional field.

Leave the field empty to create a default reference specification.

Local Subdirectory

Specify a local directory where the Git repository will be checked out. If left empty, the workspace root itself will be used.

In the Branches section, click Add to add the Git repository branch configuration options. To remove the branch, click the Remove icon.

The following table highlights what you can set in the Branches section.

Element Description

Branch Specifier

Select the branch name of the repository that you want to track. If the field is left empty, the master branch will be used.

Specify "**" to examine all branches for changes. The branch with the most recent changes will be used.

Click Advanced to set the advanced settings for the branch.

Expand the Advanced Git Settings section to configure the advanced options for the Git repository.

The following table highlights what you can set in the Advanced Git Settings section.

Element Description

Included Regions

Enter the list of files and directories that will be tracked for changes in the SCM. If a change occurs in any of the specified files or directories, a build is triggered automatically.

Each inclusion uses regular expression pattern matching, and must be separated by a new line. An empty list implies that all files and directories will be tracked.

For example, the following list illustrates that a build will be triggered when any HTML, JPEG, or GIF file is committed to the /main/web/ directory in the SCM.

myapp/src/main/web/.*\.html

myapp/src/main/web/.*\.jpeg

myapp/src/main/web/.*\.gif

Excluded Regions

Enter the list of files and directories that will not be tracked for changes in the SCM. If a change occurs in any of the specified files or directories, a build will not run.

If there is an overlap between included and excluded regions, exclusions take precedence over inclusion.

Excluded Users

Enter the list of users whose commits to the SCM will not trigger builds.

You can use literal pattern matching and users must be separated by a new line.

Checkout/merge to local branch

Specify the branch name to merge to. If specified, checkout the revision to build as HEAD on this branch.

Config user.name Value

Enter a user name value for the Git user.name variable.

Config user.email Value

Enter the user’s email address for the Git user.email variable.

Merge options

Select the Merge before build check box to perform a merge to a particular branch before running a build.

Enter the name of the repository that will be merged in Name of repository and the branch name in Branch to merge to. The build will run if the merge is successful.

Prune remote branches before build

Select the check box to run the git remote prune command for each remote to prune obsolete local branches before running a build.

Skip internal tag

Select the check box to skip the internal tag. By default, a tag is applied to the local repository after the code is checked out.

Clean after checkout

Select the check box to run the git clean -fdx command after every checkout to ensure a clean build.

Recursively update submodules

Select the check box to retrieve all sub-modules recursively.

Use commit author in changelog

Select the check box to use the commit's Author value in the build's changesets. By default, the commit's Committer value is used.

Git creates a changeset every time you do a checkin. All the files that are checked in together are included in the changeset.

Wipe out workspace before build

Select the check box to delete the contents of the workspace before running a build.

Configuring Build Triggers

Use the Build Triggers tab in the Configure Build Job page to configure options that trigger a build.

To configure build triggers:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Triggers tab.

The following table highlights what you can set in the Build Triggers section.

Element Description

When these jobs are built

Select the check box and enter the job names that will trigger this build. As soon as any of the specified jobs completes its build, a new build is scheduled for this job.

The job names must be separated by commas. For example: JobX, JobY, JobZ

Based on this schedule

Select the check box to run the build periodically. Enter the schedule information in the text box in the form of a Cron expression. See the Specifying Cron Expressions section below for a short description of the entry format.

For more information about Cron, see http://en.wikipedia.org/wiki/Cron.

Based on SCM polling schedule

Select the check box to run a build based on SCM polling.

To trigger polling at the specified schedule, enter the schedule information in the form of a Cron expression in the text box. See the Specifying Cron Expressions section for a short description of the entry format.

Polling of the project Git repository is always triggered when commits are pushed to the repository. If a schedule is also specified, polling will be triggered at every push to the repository and also at the specified schedule.

Polling of an external Git repository is triggered at the specified schedule only. It is not triggered when commits are pushed to the repository.

Select the Do not poll on SCM change check box if you do not want a build to run on every push to the project Git repository. The builds will run only on the specified schedule.

When Maven dependencies have been updated by Maven 3 integration

If the job uses Maven 3, select the check box to trigger a build when it receives a notification from other jobs that Maven dependencies of this job have been updated as a post-build action. This works in tandem with the Notify that Maven dependencies have been updated by Maven 3 integration post-build action.

Specifying Cron Expressions

If you select the Based on this schedule check box or the Based on SCM polling schedule check box, you can specify the schedule information in the following format:

MINUTE HOUR DOM MONTH DOW

where:

  • MINUTE is minutes within the hour (0-59)

  • HOUR is the hour of the day (0-23)

  • DOM is the day of the month (1-31)

  • MONTH is the month (1-12)

  • DOW is the day of the week (0-7), where 0 and 7 are Sunday

To specify multiple values, you can use the following operators:

  • * to specify all valid values

  • - to specify a range, such as 1-5

  • / or */X to specify skips of X's value through the range, such as */15 in the MINUTE field for 0,15,30,45

  • A,B,...,Z can be used to specify multiple values, such as 0,30 or 1,3,5

For example, to run a build every minute, specify * * * * * as the schedule. To run a build every five minutes, specify 5 * * * *.

You can also use @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly to schedule your builds. To add comments, use the # operator.

Configuring the Build Environment

Use the Environment tab in the Configure Build Job page to configure options for the X virtual frame buffer (Xvfb), timestamps, and Oracle Maven Repository.

To configure the build environment:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Environment tab.

The following table highlights what you can set in the Environment tab.

Element Description

Start Xvfb before the build, and shut it down after

Select the check box to start the Xvfb server before the build starts. The server will shut down after the build is complete. Xvfb is an X server that implements the X11 display server protocol and can run on machines with no physical input devices or display.

Fill in the following fields or select the following check boxes to specify how you want to configure the Xvfb server:

  • In the Xvfb Specific Display name field, specify the ordinal number of the display the Xvfb server will be running on. The default value is 0. If left empty, a random number will be chosen.

  • In the Timeout In Seconds field, specify the timeout duration for the build to wait before returning control to the job. The default value is 0.

    Because it usually takes a few seconds for Xvfb to start, some builds might fail because Xvfb did not run immediately.

  • In the Xvfb Screen field, enter the resolution and color depth of the created virtual frame buffer in the WxHxD format. For example: 1024x758x16.

  • In the Xvfb Display Name Offset field, specify the offset for display names. The default value is 1.

    Display names are taken from the build executor's number. For example, if the build is performed by the executor 4, and the offset is 100, the display name will be 104.

  • In the Xvfb Additional Options field, specify any additional Xvfb command line options, if required.

    Select the Log Xvfb output check box to redirect the output of Xvfb to the job log. Select the Shutdown Xvfb with whole job, not just with the main build action check box to keep the Xvfb server running for post-build steps.

Abort the build if it's stuck

Select the check box and specify the timeout duration in Timeout Minutes (in minutes). If a build does not complete in the specified amount of time, then the build will be terminated automatically and marked as aborted.

Select the Fail the build check box to mark the build as failed rather than marking it as aborted.

Add Timestamps to the Console Output

Select the check box to add a time stamp for each log line in the build console.

Note that the time on the build executor is UTC and the time displayed in the build job log is UTC - 7 hours.

Connect Oracle Maven Repository

Select the check box if you want to connect to Oracle Maven repository to download artifacts and dependencies for your application.

Before you run a build, you must accept the Oracle Maven repository license agreement at https://www.oracle.com/webapps/maven/register/license.html using your Oracle Technology Network (OTN) Single-Sign On (SSO) credentials.

  • OTN Login: Enter your OTN SSO user name.

  • OTN Password: Enter your OTN SSO password.

  • Server Id: If required, enter the ID to use for the <server> element of the Maven settings.xml file. If not provided, the ID will default to maven.oracle.com.

  • Custom settings.xml: If you are using a custom settings.xml file, enter the path to the file in the build workspace.

Using the Oracle Maven Repository

You can configure the POM file of your application to access the Oracle Maven Repository and configure the job to download artifacts and dependencies while running a build.

For more information about Oracle Maven repository and how to use it, see http://www.oracle.com/webfolder/application/maven/index.html.

Tutorial icon Tutorial

Here are some tips for accessing the Oracle Maven repository from Oracle Developer Cloud Service build executor:

  • Before configuring the POM file to access the Oracle Maven Repository, open https://www.oracle.com/webapps/maven/register/license.html in your web browser, sign-in with your Oracle Account credentials, and accept the license agreement.

  • To run local Maven builds on your computer, configure the Maven settings.xml file and the settings-security.xml file.

    • Configure the Oracle Maven Repository definition and add your Oracle Account user name and the password in the settings.xml file.

      Example:

      <servers>
      	<server>
      		<id>maven.oracle.com</id>
      		<username>alex.admin</username>
      		<password>password</password>
      		<configuration> ... </configuration>
      	</server>
      </servers>

      For more information, see the Configuring the Oracle Maven Repository chapter in Oracle® Fusion Middleware Developing Applications Using Continuous Integration.

    • If you want to use encrypted password, create a master password in the settings-security.xml file before you encrypt your Oracle Account password. Note that Oracle Developer Cloud Service does not store credentials in the executor Maven settings file.

      For more information about the settings.xml file and password encryption, see http://maven.apache.org/settings.html and https://maven.apache.org/guides/mini/guide-encryption.html.

    • To ensure that you are using the correct Oracle Developer Cloud Service proxy settings for your Maven build job, set the HTTP_PROXY_HOST (or HTTPS_PROXY_HOST) and HTTP_PROXY_PORT (or HTTPS_PROXY_PORT) proxy related environment variables in settings.xml.

      Example:

      <proxies>
      	<proxy>
      		<port>${env.HTTP_PROXY_PORT}</port>
      		<host>${env.HTTP_PROXY_HOST}</host>
      		<nonProxyHosts>
      			localhost|localhost.localdomain|127.0.0.1|[::1]|*.test_server.com
      		</nonProxyHosts>
      	</proxy>
      </proxies>
  • To configure a build job in Oracle Developer Cloud Service to access the Oracle Maven repository, provide your Oracle Account credentials in the Environment tab of the Job Configuration page. See Configuring the Build Environment. You don’t need to upload the local Maven files to the Git repository to run builds.

    When a build runs, Oracle Developer Cloud Service creates an internal environment to access the Oracle Maven repository. It updates the internal settings.xml (not accessible to you) to add your Oracle Account credentials, encrypts your password, run the Maven commands defined in the Build Steps tab of the Job Configuration page, and then reverts the updates made to the Maven files after the build is complete.

Configuring Build Steps

Use the Build Steps tab in the Configure Build Job page to configure various types of build steps that can then be incorporated in the build.

In the Build Steps tab, you can configure one or more of the following build steps to add:

Adding a Build Step that Runs a Shell Script

You can use the Execute shell build step to run a shell script for building the job.

To configure a build step to run a shell script:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Steps tab.

  3. Click Add Build Step and select Execute Shell.

The following table highlights what you can set in the Execute shell section.

Element Description

Command

Enter the contents of your shell script. This is a required field.

The script will run with the workspace as the current directory. If there is no header line such as #!/bin/sh — in your shell script, then the shell configured system-wide will be used, but you can also use the header line to write a script in another language (such as #!/bin/perl) or control the options that shell uses.

By default, the shell is invoked with the -ex option. All commands are printed before they run, and the build is considered a failure if any of the commands exits with a non-zero exit code. You can change this behavior by adding the #!/bin/... line.

Tip: Do not enter a long shell script in this field. For a long script, create a script file and add it in the SCM. You can run the script with a command (such as bash -ex myscript.sh) and track changes in your shell script.

Adding a Build Step that Invokes Ant

You can use the Invoke Ant build step to use Ant as the build system. When the build runs, Ant is invoked with the given targets and options. Any non-zero exit code marks the build as a failure.

To configure a build step to invoke Ant:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Steps tab.

  3. Click Add Build Step and select Invoke Ant.

The following table highlights what you can set in the Invoke Ant section.

Element Description

Targets

Specify a list of Ant targets to be invoked, or leave it empty to invoke the default Ant target specified in the build script. You can also use this field to specify other Ant options.

Build file

If your build requires a custom -buildfile, specify it here. By default, Ant will use the build.xml in the root directory; this option can be used to use build files with a different name or in a subdirectory.

Properties

Properties needed by your Ant build can be specified here (in standard properties file format):

# comment
name1=value1
name2=$VAR2

These are passed to Ant like -Dname1=value1 -Dname2=value2. Always use $VAR style for parameter references (do not use %VAR% style, even when the build runs on Windows). Slashes are used for escaping, so use \\ for a single slash. Avoid double quotes (") because Ant on UNIX wraps parameters in quotes and runs them through eval, and Windows has its own issues with escaping. In either case, the use of quotes may result in a build failure. To define an empty property, simply write varname=.

Java Options

If your build requires a custom ANT_OPTS, specify it here. Typically this may be used to specify Java memory limits to use, for example -Xmx512m. Note that other Ant options (such as -lib) should go to the Targets field.

Adding a Build Step that Invokes Maven 2

You can use the Invoke Maven 2 (Legacy) build step to use Maven 2 as the build system. When a build runs, Maven is invoked with the given goals and options. A non-zero exit code from Maven marks the build as a failure. Note that some Maven versions have a bug that causes Maven not to return the exit code correctly.

You can access various Maven environment variables with ${env.VARIABLENAME}.

The variables can be used in command-line arguments (as if you are invoking Maven from a shell). For example, you can specify -DresultsFile=${WORKSPACE}/${BUILD_TAG}.results.txt.

To configure a build step to invoke Maven 2:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Steps tab.

  3. Click Add Build Step and select Maven 2.

The following table highlights what you can set in the Invoke Maven 2 (Legacy) section.

Element Description

Maven Version

Select the Maven version from the list.

Goals

Enter the Maven project goals.

POM

Enter the name and path of the project's POM file

Properties

Specify the properties (in standard properties file format) needed by your Maven build:

# comment
name1=value1
name2=value2

These are passed to Maven as -Dname1=value1 -Dname2=value2.

JVM Options

Specify Java Virtual Machine options, if necessary.

Use private Maven repository

Select the check box to enable Maven to use a private repository in the project workspace in a .maven/repo folder. Enabling this option increases the usage of storage space, which should be monitored carefully.

Adding a Build Step that Invokes Maven 3

You can use the Invoke Maven 3 build step to use Maven 3.0 or higher as the build system. When a build runs, Maven is invoked with the given goals and options. A non-zero exit code marks the build as a failure. Some Maven versions have a bug that causes Maven not to return the exit code correctly.

To configure a build step to invoke Maven 3:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Build Steps tab.

  3. Click Add Build Step and select Maven 3.

The following table highlights what you can set in the Invoke Maven 3 section.

Element Description

Maven 3

Select (Bundled) to use the bundled Maven 3 installation.

Goals

Enter Maven goals, or phases, to run. This is a required field.

For example: clean and install are added by default.

For more information about Maven goals, see the Maven Lifecycle Reference documentation at http://maven.apache.org.

Properties

Enter custom system properties in the key=value format. This is an optional field.

POM File

Enter the Maven POM file name and location, relative to the workspace root. This is an optional field.

Private repository

Select the check box to use a private repository for builds. This is an optional field.

Private temporary directory

Select the check box to use a private temporary directory for builds. This is an optional field.

Offline

Select the check box to work offline. This is an optional field.

Profiles

Enter the list of profiles to activate. The list can be comma or space separated. This is an optional field.

For more information about Maven profiles, see the Maven documentation at http://maven.apache.org.

Show Errors

Select the check box to produce execution error detail messages. This is an optional field.

Verbosity

Select the Maven verbosity level from the list. You can select the level as NORMAL, QUIET, or DEBUG. This is an optional field.

Checksum Mode

Select the checksum handling mode from the list. You can select the mode as NORMAL, STRICT, or LAX. This is an optional field.

Snapshot Updates

Select how SNAPSHOT artifact updates are handled. You can select the handling mode as NORMAL, FORCE, or SUPPRESS. This is an optional field.

Recursive

Indicates that all sub-modules will build recursively. The check box is selected by default. This is an optional field.

Projects

Enter the list of projects to include in the reactor. The reactor is a mechanism in Maven that handles multi-module projects. This is an optional field.

A project can be specified by [groupId]:artifactId or by its relative path. The list can be comma or space separated.

Resume From

Enter the project name from where you would like to resume the reactor. The project can be specified by [groupId]:artifactId or by its relative path. This is an optional field.

Fail Mode

Select the failure handling mode from the list. You can select the handling mode as NORMAL, AT_END, FAST, or NEVER. This is an optional field.

Make Mode

Select the Make-like reactor mode from the list. You can select the mode as NONE, DEPENDENCIES, DEPENDENTS, or BOTH. This is an optional field.

Threading

Enter the configuration of the reactor threading model. This is an optional field.

JVM Options

Enter the parameters to be passed to the Java VM when running Maven via the MAVEN_OPTS environment variable. This is an optional field.

Adding a Build Step that Invokes Gradle Script

You can use the Gradle script build step for projects to use Gradle build automation tool as the build system. When a build runs, Gradle is invoked with the given goals and options. A non-zero exit code marks the build as a failure.

For more information about Gradle, see https://gradle.org/.
To configure a build step to invoke a Gradle script:
  1. Open the Configure Build Job page of the job.
  2. Click the Build Steps tab.
  3. Click Add Build Step and select Invoke Gradle script.

The following table highlights what you can set in the Invoke Gradle script section.

Element Description

Invoke Gradle

Select to invoke Gradle script to run builds.

Use Gradle Wrapper

Select to use Gradle wrapper script to run builds.

Gradle Version

If you selected Invoke Gradle, select the Gradle version from the list.

Make gradlew executable

If you selected Use Gradle Wrapper, select the check box to make the gradlew command as an executable command.

From Root Build Script Dir

If you selected Use Gradle Wrapper, select the check box to use the gradlew command from the root build script directory.

Build step description

Enter the description of the build step.

Switches

Enter Gradle switches to be invoked.

Tasks

Enter Gradle tasks to be invoked

Root Build script

Enter the path of the top-level build.gradle file if it is available in a directory other than the module root directory. The specified path must be relative the module root directory.

If left empty, the path defaults to build.gradle in the module root directory.

Build File

Enter the name of the Gradle build file if it is not named as build.gradle.

Force GRADLE_USER_HOME to use workspace

If you are using a multi-executor slave, select the check box to set the GRADLE_USER_HOME to the workspace and avoid collisions while accessing Gradle cache.

By default, GRADLE_USER_HOME is set to $HOME/.gradle.

To view the dependency information of an artifact, see Browsing the Project Maven Repository.

Note:

To download the external dependencies during a build, configure the proxy settings using the Gradle proxy configuration. See https://docs.gradle.org/current/userguide/build_environment.html.

Adding a Build Step that Invokes Node.js

You can add a Node.js build step that invokes a Node.js script when the build runs.

To configure a build step to invoke a Node.js script:
  1. Open the Configure Build Job page of the job.
  2. Click the Build Steps tab.
  3. Click Add Build Step and select Invoke NodeJS.

The following table highlights what you can set in the Invoke Node.js script section.

Element Description

NodeJS Installation

Select the version of the Node.js compatible with the script that you want to run.

Script

Enter the Node.js script code that you want to run.

Adding a Build Step that Copies Artifacts from Another Job

You can add a build step that copies artifacts from another build job.

To configure a build step to copy artifacts from another job:
  1. Open the Configure Build Job page of the job.
  2. Click the Build Steps tab.
  3. Click Add Build Step and select Copy Artifacts from Another Job.

The following table highlights what you can set in the Copy Artifacts from Another Job section.

Element Description

Job Name

Select the job whose artifacts you want to import.

Which Build

Select the build that generated the artifacts. You can choose from the following options:

  • Latest Successful Build: Import artifacts from the last successful build.

    Select the Stable build only check box to import artifacts from stable builds only.

  • Latest saved build (marked "keep forever"): Import artifacts from the latest build that is marked as Keep Forever.

    For more information about how to mark a build as Keep Forever, see Viewing Build Details

  • Upstream build that triggered this job: Import artifacts from the upstream build.

    Select the Use "Last successful build" as fallback check box to use the artifacts from the last successful build if an error occurs in the upstream build.

  • Specified by permalink: Import artifacts from the job specified by Permalink.

    In the Permalink list, select the desired permalink option.

  • Specific build: Import artifacts from the selected build number in Build Number.

    In Build Number, specify the build number of the job whose artifacts you want to copy.

  • Specified by a build parameter: Import artifacts from the build with the parameter specified in Parameter Name.

  • Copy from WORKSPACE of latest completed build: Import artifacts from the WORKSPACE of the latest build.

Artifacts to copy

Specify the artifacts that you want to import with their relative paths.

Mouse over the artifact link to view its path in the Artifacts of the Last Successful Build section of the Job Details page or the Build Artifacts section of the Build Details page.

All artifacts are stored in the artifacts directory of the build. To specify an artifact in a subdirectory (example: /artifacts/testdir/hello.war), enter the relative path of the artifact (example: testdir/hello.war).

Target Directory

Specify the target directory where the artifacts will be imported.

Select the Flatten Directories check box to flatten the target directory structure after importing artifacts.

Select the Optional check box if the target directory is optional.

Adding a Build Step that Invokes SQLcl

You can add a SQLcl build step that invokes SQL statements on an Oracle Database when the build runs.

You can use the SQLcl build step to access any Oracle Database that you can access using a JDBC connect string. You can run DML, DDL, and SQL Plus statements. You can also use the SQLcl build step in your test scenario to run SQL scripts to initialize seed data or validate database changes. To know more about SQLcl, see http://www.oracle.com/technetwork/developer-tools/sqlcl/overview/index.html.
To configure a build step to invoke SQL statements:
  1. Open the Configure Build Job page of the job.
  2. Click the Build Steps tab.
  3. Click Add Build Step and select Invoke SQLcl.

The following table highlights what you can set in the Invoke SQLcl section.

Element Description

Username

Enter the user name of the Oracle Database account.

Password

Enter the password of the Oracle Database account.

Connect String

Enter the JDBC connection string of the Oracle Database account using any of the host_name:port:SID or host_name:port/service_name formats.

Examples: test_server.us.oracle.com:1521:adt1100 where adt1100 is the SID, and test_server.us.oracle.com:1521/ora11g where ora11g is the service name.

Source

Select SQL File if the SQL statements are in a file uploaded to the project Git repository.

Select Inline SQL to specify the SQL statements.

SQL File Path

If you selected SQL File in Source, enter the Git workspace path of the SQL file.

SQL Statements

If you selected Inline SQL in Source, enter the SQL statements in the code editor.

Role

Select the database role of the user. By default, it is set to Default.

Restriction Level

Specify the restriction level on the type of SQL statements that are allowed to run. By default, it is set to 0.

When a build runs, your Oracle Database credentials are stored in an Oracle Wallet. Check the build’s console for the SQL output or errors.

Note:

  • SQL commands that are specific to editing buffer (such as set sqlformat csv) or editing console will not work.

  • You can use build parameters in Username, Password, Connect String, and SQL Statements fields. You cannot use build parameters in the SQL file. See Configuring Build Parameters.

Adding a Build Step that Invokes PSMcli Commands

You can add a PSMcli build step that invokes Oracle PaaS Service Manager command line interface (CLI) commands when the build runs.

You use PSMcli commands to manage the lifecycle of various services in Oracle Public Cloud. For more information about PSMcli and its commands, see About the PaaS Service Manager Command Line Interface in PaaS Service Manager Command Line Interface Reference.

To configure a build step to invoke PSMcli commands:
  1. Open the Configure Build Job page of the job.
  2. Click the Build Steps tab.
  3. Click Add Build Step and select Invoke PSMcli.

The following table highlights what you can set in the Invoke SQLcl section.

Element Description

Username

Enter the user name of the Oracle Cloud account.

Password

Enter the password of the Oracle Cloud account. The password is saved in a keystore plug-in in an encrypted format.

Identity Domain

Enter the identity domain.

Region

Select your identity domain’s region: US (default) or EMEA.

Output Format

Select the preferred output format: JSON (default) or HTML.

PSM Commands

Enter PSM commands that you want to run when the build runs.

For example, you can run commands to start or stop other Oracle Cloud PaaS environments when you run the build.

You can also use build parameters in above fields. See Configuring Build Parameters.

Configuring Post Build Actions

You use the Post-build Actions tab in the Configure Build Job page to configure actions you want the system to perform after the build completes. These actions can include building other jobs, archiving artifacts, publishing javadoc, recording fingerprints of files and artifacts, and providing notification when Maven dependencies have been updated by a Maven 3 integration.

To configure the post build steps:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Post Build tab.

The following table highlights what you can set in the Post-build tab.

Element Description

Aggregate downstream test results

Because tests often dominate the execution time, you should try to split the test executions into different jobs, possibly in multiple different jobs.

When you do that, setting test aggregation is a convenient way of collecting all the test results from such downstream test jobs and displaying them along with the build that they are testing. In this way, people can see the overall test status of the given build quickly.

Select the Automatically aggregate all downstream tests check box to aggregate tests from all the transitive downstream jobs of this job. This is convenient because you don't have to individually list them and keep them up to date as you add or remove jobs. This normally works fine because your test jobs are normally set up as downstream jobs of the build job.

If for some reasons the auto aggregation doesn't work, you can always manually specify a list of jobs to be aggregated.

Build other jobs

Select the check box to trigger builds of other jobs after a build is successfully completed. Multiple jobs can be specified by using commas, such as job_abc, job_def.

If you want to build other jobs that have a dependency on the current job, it would be useful to split a long build process into multiple stages (such as the build portion and the test portion).

In the Jobs to build field (required), enter the list of additional builds to run after the initial build completes. Select the Trigger even if the build is unstable check box if you want to run the unstable builds from the list too.

Archive the artifacts

Select the check box to archive the build artifacts (for example, distribution ZIP files or JAR files) so that they can be downloaded later.

Normally, artifacts for a build are kept as long as the build log is kept, but if you don't need old artifacts and would rather save disk space, you can do so.

Fill in the following fields or select the following check boxes to configure how you want the artifacts to be archived:

  • In the Files to archive field (required), enter the file names that you want to archive.

    You can use wildcards like module/dist/**/*.zip. For more information, see the @includes attribute of the Ant fileset (see http://ant.apache.org/manual/Types/fileset.html) for the exact format. The base directory is the workspace.

  • Select the Enable auto validation for file masks check box to enable automatic validation for file masks.

  • Optionally, in the Excludes field, specify the "excludes" pattern (see http://ant.apache.org/manual/Types/fileset.html), such as foo/bar/**/*. A file that matches this mask will not be archived even if it matches the mask specified in the Files to archive field.

  • Select the Discard all but the last successful/stable artifact to save disk space check box to discard most artifacts from older builds. Artifacts from the last stable former build (if any) are kept, and also those from the last unstable build if that is newer, and from the last failed build if that is newer.

    This option saves disk space, but still lets you safely create permalinks such as .../lastStableBuild/artifact/... or .../lastSuccessfulBuild/artifact/... or .../lastCompletedBuild/artifact/....

  • Use the Compression Type list to select the compression type, which will be applied to the selected artifacts before the master-slave transfer.

    The default value is GZIP. A TGZ file is created on the slave host, is sent to the master, and is extracted there. Select NONE to disable compression in case of a weak server and wide network bandwidth, or in case of already packed artifacts (*.jar, *.war, etc).

Record fingerprints of files to track usage

The Oracle Developer Cloud Service build executor can record the "fingerprint" of files, most often JAR files, to keep track of when and where those files are produced and used. When you have interdependent jobs, this allows you to quickly find out answers to questions like:

  • I have an abc.jar file on my disk, but which build number of the ABC job did it come from?

  • My other job, XYZ, depends on abc.jar from the ABC job. Which build of abc.jar is used in XYZ #51?

  • Which build of the ABC job contains my bug fix to abc.jar #32?

Select the Record fingerprints of files to track usage check box to fingerprint the Maven artifacts used or produced within the build to keep track of where or when those files are produced and used.

In the Files to fingerprint field (required), enter the files that you want to fingerprint. You can also use wildcards.

Select the Fingerprint all archived artifacts check box to fingerprint all artifacts generated by the build.

Select the Keep the build logs of dependencies check box to protect from log rotation all builds that are referenced from builds of this job (via fingerprint).

Note: To use the fingerprint recording feature, all of the involved jobs (not just the job in which a file is produced, but also the jobs in which the file is used) need to use this and record fingerprints. See http://wiki.eclipse.org/Hudson-ci/fingerprint.

Publish Javadoc

Select the check box to configure how and where to publish Javadoc that is generated during a build.

Enter a directory relative to the root of the workspace, such as myjob/build/javadoc, in the Javadoc directory field (required).

If you select the Retain Javadoc for each successful build check box, the build executor will retain Javadoc for each successful build. This allows you to browse Javadoc for older builds, at the expense of additional disk space. If you leave this option unchecked, the build executor will only keep the latest Javadoc, so older Javadoc will be overwritten as new builds succeed.

Publish JUnit test result report

Select the check box to get useful information about test results, such as historical test result trends, failure tracking, and so on.

To use this feature, you must first set up your build to run tests, then specify the path to JUnit XML files in the Ant syntax, such as **/build/test-reports/*.xml. If you are using Maven, specify the path of JUnit XML files as target/surefire-reports/*.xml. Be sure not to include any non-report files into this pattern.

See http://ant.apache.org/manual/Types/fileset.html.

In the Test Report XMLs field (required), enter the fileset includes setting that specifies the generated raw XML report files, such as myjob/target/test-reports/*.xml. The basedir of the fileset is the workspace root.

Select the Retain long standard output/error check box to see standard output and errors in the test results after the build completes. The output is always saved in case the test fails, but by default, lengthy output is truncated to save space. You must select the check box if you want to see every log message, but note that memory consumption can substantially increase as a result and can slow the performance of the build server.

Select the Organize test output by parent location check box to organize the output by parent’s location.

Archive Maven 3 artifacts

Select the check box to archive the Maven 3 artifacts created by the build.

By default, only the generated artifacts are archived, but you can also archive the project POM files.

Select the Include generated POMs check box to also archive the Maven 3 project POM files from the build.

Select the Discard old artifacts check box to retain the most recent artifacts only. All older Maven 3 artifacts will be deleted.

Record fingerprints of Maven artifacts

Select the check box to fingerprint the Maven artifacts used or produced within the build to keep track of where or when those files are produced and used.

Git publisher

Select the check box to push merge results, tags, and branches to remote repositories.

Select the Push only if build succeeds check box to push to remote repositories only if the build succeeds. Otherwise, nothing will be pushed.

Select the Merge results check box to push merges back to the origin specified in the pre-build merge options. If pre-build merging is configured, push the result back to the origin.

Tags to push to remote repositories section

Use the Tags to push to remote repositories section to specify tags to push at the completion of the build. The section appears after the Git publisher check box is selected.

Click Add to add a tag or repeat the operation to add multiple tags:

  • Enter the name of a tag to push in the Tag to Push field. This field is required.

    Environment variables may be used in the tag name - they will be replaced at build time.

  • If you select the Create new tag check box, the tag will be created and pushed at the completion of the build. The push will fail, however, if a tag with the given name already exists.

    If the Create new tag check box is not selected, the push will fail if the tag does not already exist.

  • Enter the name of a remote repository in the Target Remote Name field (required).

    The repository name needs to be one of the repositories configured in the Source Code Management section. See Configuring the Source Code Management System for Builds.

Branches to push to remote repositories section

Use the Branches to push to remote repositories section to specify remote branches to push the current HEAD to, at the completion of the build. The section appears after the Git publisher check box is selected.

Click Add to add a branch or repeat the process to add multiple branches.

  • Enter the name of the remote branch in the Branch To Push field. This field is required.

    Environment variables may be used in the branch name; they will be replaced at build time.

  • Enter the name of the target repository where the branch resides in the Target Remote Name field. This field is required.

    The repository name needs to be one of the repositories configured in the Source Code Management section. See Configuring the Source Code Management System for Builds.

Notify that Maven dependencies have been updated by Maven 3 integration

Select the check box to notify jobs that consume Maven artifacts generated by the current build that there have been updates. This option works in tandem with the Build when Maven dependencies have been updated trigger.

If you want to build other jobs that have a dependency on the current job, it would be useful to split a long build process into multiple stages (such as the build portion and the test portion).

Select the Notify even when build is unstable check box to indicate that notifications should be made even when the build is unstable.

Oracle Cloud Service Deployment

Select the check box and configure deployment actions of the specified deployment configuration. The build will be successful if the deployment action is successful.

A deployment configuration must exist before you configure the deployment actions of the job. If required, create a deployment configuration to meet your requirements. For more information, see Creating a Deployment Configuration.

After selecting the check box, select one of the following deployment actions from the Add Deploy Task list.

  • Deploy: Select the deployment configuration from the list that will deploy the build generated artifact to the target Java Cloud Service instance. The list shows only those deployment configurations where the name of the job and the name of the deployment configuration match, and the deployment configuration is of type On Demand.

    The list is empty if the names do not match or the deployment configuration is of type Automatic.

  • Undeploy: Select the deployment configuration to undeploy from the target Java Cloud Service instance.

  • Start: Select the deployment configuration to start on the target Java Cloud Service instance.

  • Stop: Select the deployment configuration to stop on the target Java Cloud Service instance.

You can configure more than one deployment actions in a job.

Note:

If you change a deployment configuration or delete it after specifying the deployment action in the job, the changes are not reflected in the job and the build might not run as expected.

For example, if you change the deployment configuration’s type to Automatic after specifying the deployment action in the job, the artifact will get deployed twice. The first deployment will happen when the build is successful. The deployment will then trigger the next automatic deployment action of the deployment configuration.

If you delete a deployment configuration or rename it after specifying the deployment action in the job, the build will attempt to deploy the artifact and will fail as the deployment configuration has been deleted or renamed.

When you change a deployment configuration, make sure that you update the build’s deployment action as well.

Setting Advanced Options for the Job

Use the Advanced tab in the Configure Build Job page to configure the advanced options for the job, such as quiet period and retry count.

To configure the build environment:

  1. Open the Configure Build Job page of the job.

    See Configuring a Job.

  2. Click the Advanced tab.

The following table highlights what you can set in the Advanced tab.

Element Description

Quiet period

Select the check box and specify the period (in seconds) a new scheduled build should wait before it runs in Quiet Period.

If the build server is busy with too many builds, setting a longer quiet period can reduce the number of builds.

Retry count

Select the check box and specify the number of times the build executor will retry the build if it fails to checkout files from the Git repository in SCM Checkout.

Block build when upstream job is building

Select the check box to stop the build from running if a dependent build of the project is in the queue, or is running.

Block build when downstream job is building

Select the check box to stop the build from running if a child build of the project is in the queue, or is running.

Using the Oracle Developer Cloud Service Build Executor Environment Variables

When you run a build job, you can use the environment variables in your shell scripts and commands to access the software on the Oracle Developer Cloud Service build executor.

The following table describes some common environment variables.

Environment Variable Description

BUILD_ID

The current build’s ID.

BUILD_NUMBER

The current build number.

BUILD_URL

The full URL of the current build.

DYNAMO_HOME

The path of the Oracle ATG home directory.

DYNAMO_ROOT

The path of the Oracle ATG root directory.

GRADLE_HOME

The path of the Gradle directory.

JOB_NAME

The name of the job.

EXECUTOR_NUMBER

The unique number that identifies the current executor (among executors of the same machine) that's running the current build.

JAVA_HOME

The path of the directory where the Java Development Kit (JDK) or the Java Runtime Environment (JRE) is installed.

If your job is configured to use a specific JDK, the build executor sets the variable to the path of the specified JDK. When the variable is set, PATH is also updated to have $JAVA_HOME/bin.

JAVACLOUD_HOME

The path of the Oracle Java Cloud Service - SaaS Extension Software Development Kit directory.

The following JDeveloper and SOA related variables are also available:

  • JAVACLOUD_HOME_11_1_1_7_1=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper/cloud/oracle-javacloud-sdk/lib

  • JAVACLOUD_HOME_11G=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper/cloud/oracle-javacloud-sdk/lib

  • JAVACLOUD_HOME_12C3=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper/cloud/oracle-javacloud-sdk/lib

  • JAVACLOUD_HOME_SOA=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper/cloud/oracle-javacloud-sdk/lib

  • JAVACLOUD_HOME_SOA_12_1_3=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper/cloud/oracle-javacloud-sdk/lib

  • JAVACLOUD_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1.1/jdeveloper/cloud/oracle-javacloud-sdk/lib

HTTP_PROXY

The HTTP proxy for outgoing connections.

HTTP_PROXY_HOST

The HTTP proxy host for outgoing connections.

HTTP_PROXY_PORT

The HTTP proxy port for outgoing connections.

HTTPS_PROXY

The HTTPS proxy for outgoing connections.

HTTPS_PROXY_HOST

The HTTPS proxy host for outgoing connections.

HTTPS_PROXY_PORT

The HTTPS proxy port for outgoing connections.

HUDSON_HOME

The path of the Hudson home directory.

HUDSON_URL

The full URL of the Hudson server.

JOB_NAME

The name of the current job.

JOB_URL

The full URL of the current job.

NO_PROXY

Specify the comma separated list of domain names or the IP addresses for which the proxy should not be used. You can also specify port numbers.

NO_PROXY_ALT

Specify the pipe ( | ) separated list of domain names or the IP addresses for which the proxy should not be used. You can also specify port numbers.

NODE_HOME

The path of the Node.js home directory.

NODE_PATH

The path of the Node.js modules directory.

If you are using JDeveloper or developing an Oracle ADF application and want to run ojdeploy scripts, you can use the variables described in the following table.

Environment Variable Description

ORACLE_HOME

The path of the directory where JDeveloper is installed on the build executor.

The following variables are available:

  • ORACLE_HOME=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper

  • ORACLE_HOME_11G=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper

  • ORACLE_HOME_11_1_1_7_1=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper

Use the following variables for JDeveloper with SOA :

  • ORACLE_HOME_12C3=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper

  • ORACLE_HOME_SOA=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper

  • ORACLE_HOME_SOA_12_1_3=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper

  • ORACLE_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1/jdeveloper

MIDDLEWARE_HOME

The path of the directory where Oracle Fusion Middleware is installed on the build executor.

The MIDDLEWARE_HOME directory includes the JDeveloper installation directory, WebLogic Server installation directory, and the Oracle Common library dependencies.

The following variables are available:

  • MIDDLEWARE_HOME=/opt/Oracle/Middleware_11.1.1.7.1

  • MIDDLEWARE_HOME_11G=/opt/Oracle/Middleware_11.1.1.7.1

  • MIDDLEWARE_HOME_11_1_1_7_1=/opt/Oracle/Middleware_11.1.1.7.1

Use the following variables for SOA :

  • MIDDLEWARE_HOME_12C3=/opt/Oracle/MiddlewareSOA_12.1.3

  • MIDDLEWARE_HOME_SOA=/opt/Oracle/MiddlewareSOA_12.1.3

  • MIDDLEWARE_HOME_SOA_12_1_3=/opt/Oracle/MiddlewareSOA_12.1.3

  • MIDDLEWARE_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1.1

WLS_HOME

The path of the WebLogic server binary directory bundled with the JDeveloper install on the build executor.

The following variables are available:

  • WLS_HOME=/opt/Oracle/Middleware_11.1.1.7.1/wlserver_10.3

  • WLS_HOME_11G=/opt/Oracle/Middleware_11.1.1.7.1/wlserver_10.3

  • WLS_HOME_11_1_1_7_1=/opt/Oracle/Middleware_11.1.1.7.1/wlserver_10.3

Use the following variables for SOA :

  • WLS_HOME_12C3=/opt/Oracle/MiddlewareSOA_12.1.3/wlserver

  • WLS_HOME_SOA=/opt/Oracle/MiddlewareSOA_12.1.3/wlserver

  • WLS_HOME_SOA_12_1_3=/opt/Oracle/MiddlewareSOA_12.1.3/wlserver

  • WLS_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1/wlserver

Tip:

You can run the env command as a Shell build step to view all environment variables set on the Oracle Developer Cloud Service build executor. See Adding a Build Step that Runs a Shell Script.

About the Software Installed on the Oracle Developer Cloud Service Build Executor

Various software, such as JDeveloper, Xvfb, and Node.js, are installed on the Hudson Slave Agents of Oracle Developer Cloud Service and are available to the Executor threads when running on the Cloud.

Executables from the software bundles are available on the builder's PATH variable, which is set to/usr/bin, and can be invoked directly from the Execute Shell build steps. You should use the PATH variable and other environment variables to access the installed software.

The following table lists software installed on the Hudson Slave Agents in addition to the software installed on the operating system.

Software Version on Oracle Linux 6 and Oracle Linux 7 Version on Oracle Solaris x86

Findbugs

3.0.1

3.0.1

Firefox

yum:latest

IPS:latest

Gradle

2.14.1

2.14.1

Node.js

0.12.7

4.x

6.x

Not Available

Node.js – grunt

0.4.5

Not Available

Node.js – gulp

3.9.0

Not Available

Node.js – grunt-cli

0.1.13

Not Available

Node.js – gulp-cli

0.3.0

Not Available

Node.js – bower

1.7.7

Not Available

Node.js – oracledb

1.7

Not Available

Node.js Driver for Oracle Database

12.1.0.2

Not Available

Oracle ATG 11.1.0.1

11.1.0.1

Not Available

Oracle Developer Studio 12.5

12.5

12.5

Oracle Instant Client 12c

12.1.0.2.0

12.1.0.2.0

Oracle JDeveloper 11g

11.1.1.7.1

11.1.1.7.1

Oracle SOA Suite 12c

12.2.1.1.0

12.1.3.0.0

12.2.1.1.0

Python3

3.5.2

3.4.3

Python3 – pip

9.0.1

9.0.1

Ruby

yum:latest

IPS:latest

SFTP

yum:latest

IPS:latest

Xvfb

yum:latest

1.14.5

To know about the environment variables that you can use to access the software, see Using the Oracle Developer Cloud Service Build Executor Environment Variables.

Note:

Various plugins such as Gradle, Node, Xvfb, and Maven 3 ported from Eclipse/Community Hudson are also available in the build executor.

Running a Build

You can run a job’s build from the job’s details page and Jobs Overview page.

To run a build of a job:
  1. In the navigation bar, click Build.
  2. In the Jobs table, click the job name link.
  3. In the job’s details page, click Build Now.
You can also run a job’s build from the Jobs Overview page. In the jobs table, click the Build Now icon to run the build of the corresponding job.

Configuring a Job to Run a Maven Build

Apache Maven is pre-installed on the Oracle Developer Cloud Service build executor. You can use Maven 2.0 or 3.0 to run builds of your application.

To run Maven builds:

  1. Configure your application to use the Maven POM file.

    If you are new to Maven, see https://maven.apache.org/.

  2. Commit and push the application files to the project Git repository.

  3. Create a job and configure it

    For more information, see Creating a Job and Configuring a Job.

  4. Configure the job to use Maven as a build step.

    For more information, see Adding a Build Step that Invokes Maven 2 and Adding a Build Step that Invokes Maven 3.

  5. Save the job and run a build.

    For more information, see Running a Build.

While you are configuring a job to use Maven, you might also want to take a look at the following topics:

Configuring a Job to Run an Ant Build

Apache Ant is pre-installed on the Oracle Developer Cloud Service build executor.

To run Ant builds:

  1. Configure your application to use the Ant build files.

    If you are new to Ant, see https://ant.apache.org.

  2. Commit and push the application files to the project Git repository.

  3. Create a job and configure it

    For more information, see Creating a Job and Configuring a Job.

  4. Configure the job to use Ant as a build step.

    For more information, see Adding a Build Step that Invokes Ant.

  5. Save the job and run a build.

    For more information, see Running a Build.

While you are configuring a job to use Ant, you might also want to take a look at the following topics:

Configuring the POM File to Upload or Download Dependencies from the Project Maven Repository

You can configure the pom.xml file to upload or download dependencies from the project Maven repository while running a build.

To configure the pom.xml file:
  1. In the navigation bar, click Maven.
  2. In the Browse view of the Maven page, click the Maven tab in Distribution Management.
  3. Click the Copy to clipboard to copy the <distributionManagement> code snippet to the clipboard.
  4. Open the pom.xml file of your project in a code editor (or a text editor) and paste the contents of the clipboard under the <project> element.
  5. Save the file, commit it to the Git repository, and then push the commit.

Note:

The credentials in settings.xml are not required to access the project Maven repository when running a build. The Build job has full access to the project Maven repository for uploads and downloads.

Downloading Build Artifacts

You can download the job’s last successful build’s artifacts from the job’s details page and from the build’s details page.

The build artifacts are displayed in a directory tree structure. You can click the link to download parts of the tree including individual files, directories, and subdirectories.
To download artifacts of the job’s last successful build:
  1. In the navigation bar, click Build .
  2. In the Jobs table, click the job name link.
  3. In the Artifacts of Last Successful Build section of the job’s details page, click the artifact link (file or directory) to download it.
    Click (all files in zip) to download all artifact files in a zip.
To download artifacts of a particular build, open the build’s details page, and download the artifacts from the Build Artifacts section. For more information, see Viewing Build Details.

Subscribing to a Job’s Build Email Notifications

You can subscribe to email notifications when a build of a job is successful or fails.

Before you subscribe to build email notifications, enable the build activity notifications in your account preferences. See Setting Email Notifications.

To subscribe to a job’s build email notifications:

  1. In the navigation bar, click Build.

  2. In the Jobs table, click the job name link.

  3. If necessary, click the On toggle button to enable build notifications of the job for all subscribed users. The email notifications are enabled by default.

  4. Click the CC Me icon to subscribe yourself to the job’s build email notifications.

  5. In the CC Me dialog, select the Successful Builds check box to receive email when the build is successful. Select Failed Builds to receive email when the build fails.

  6. Click OK.

When you are subscribed to a job’s build email notifications, the CC Me icon changes to CCed Me.

To unsubscribe to email notifications, click CCed Me, and deselect the required check box.

Note:

Do not click the Off toggle button to unsubscribe to your email notifications. The Off toggle button disables email notifications for all users.

Viewing Build Details

From the build’s details page, you can view its status, duration, and download the artifacts.

To view build details:

  1. In the navigation bar, click Build.

  2. Click the job name link.

  3. Click the build number link in the Build History table. You can also click the build number link in the job page.

The following graphic shows the details page of the hrapp_maven – Build 8 build.

The following table highlights what you can do from the build page.

Element Description

Delete

Deletes the build.

Edit Description

Add or edit the build description.

The description is helpful if you mark a particular build to keep it forever and not get discarded automatically.

Keep forever

Click the button to mark a build and keep it forever.

When marked, the build is not discarded if you have selected the Select the Discard Old Builds check box and configured the job to remove old builds automatically.

The Delete button is also disabled. The build is deleted when the parent job is deleted.

To reset the build’s keep forever setting, click Don’t keep forever.

< Jobs Overview | Job Name | < #Build Number >

Click < Jobs Overview to return to the Jobs Overview page.

Click the job name link to return to the job details page.

Click the < or the > icons around the build number to navigate to the previous build or the next build.

Status

Displays the status of the build.

Time

Displays the time when the build was started.

Started By

Displays the name of the member who started the build

Duration

Displays how long the build ran.

Description

Display’s build description.

Build Parameters

Displays the build parameters, their values, and their description if the build is successful.

Build Artifacts

Expand to view the download links of artifacts. Links are available when a build is successful.

Changes

Expand to view the recent changes made to the build.

The Changes page displays a summary of the files that were edited or added.

Console

View the console output of the build.

Git Logs

View the Git polling log of the build.

View Tests Log

View the log of build’s JUnit tests.

Viewing a Build’s Console Output

After a build has run, you can view its log in the build console.

To view a build’s console:
  1. In the navigation bar, click Build.
  2. Click the Job name link.
  3. In the Build history table, click the Console icon.
    You may also click the build number and then click the Console icon in the Build Details page.
In the Console Output page, review the build log. If the log is displayed partially, click the Full Log link to view the entire log. To download the log as a text file, click the Download Console Output link.

Tip:

  • In the Jobs Overview page, click the Console icon to view the log of the last build of a job.

  • In the Job Details page of a job, click the Latest Console icon to view the build log of the last build.

Viewing a Build’s Recent Changes

If a build is triggered by a commit to the Git repository, you can view the Change log to see the files that were recently edited or added to the repository.

To view the Change log:
  1. In the navigation bar, click Build.
  2. In the Jobs Overview page, click the job name.
  3. In the Build History table, click the build number link.
  4. Click the Changes icon.
The Change log shows all files that have changed in the current build.

Tip:

In the Job Details page of a job, click the Changes icon to view the Change log of the last build.

Viewing a Build’s Test Results

You can view the JUnit and Selenium test results of a build from the build’s details page.

To view a build’s test results:
  1. In the navigation bar, click Build.
  2. Click the job name link.
  3. Click Tests to view test results of the latest build.
    To view test results of a particular build, click the build number link in the Build History table, and then click Tests.

The test results page displays the following information.

Element Description

Metrics

Shows details of the tests, including total number of tests, total failed tests, total skipped tests, and the total run time of tests.

All Failed Tests

Click the toggle button to view details of the failed tests.

The information of all tests is shown in a table format with following columns:

  • Image: Click the Show link to download the test image. The image file name is same as the test name followed by —failed.

    For example, if the test name is TestBuildPage.checkBuildCopyJob, the image file name would be TestBuildPage.checkBuildCopyJob-failed.img.

  • Test Name: Displays the test name. Click the name link to open the test details page.

  • Duration: Displays the test duration.

  • Age: Displays how old the test is.

All Tests

Click the toggle button to view details of all test suites.

The information of all tests is shown in a table format with following columns:

  • Video: Click the Watch link to download the test video file. The video file name is same as the test suite name.

    For example, if the test suite name is TestBuildPage, the video file name would be TestBuildPage.webm.

  • Suite Name: Displays the test suite name. Click the name link to open the test suite details page.

  • Duration: Displays the test suite duration.

  • Failed: Displays the number of tests of the suite that failed.

  • Skipped: Displays the number of tests of the suite that were skipped.

  • Total: Displays the number of tests of the suite.

Test Results History

Opens the Test Results History page that displays the history of all tests and its graphical representation.

Viewing Test Results History

The Test Results History page shows a graphical representation of all tests of the job.

To view the Test Results History page:
  1. Open the Test Results page.
  2. Click Test Results History.
The results page shows the following information.
Element Description

Graph

Shows a graphical representation of the passed, skipped, and failed tests.

Mouse over the graph bar to view more details.

Build

Displays the job name and the build number of the test. Click the link to open the Test Results page of the build.

Duration

Displays the total duration of the all tests of the build.

Failed

Displays the total failed tests of the build.

Skipped

Displays the total skipped tests of the build.

Total

Displays the total number of tests of the build.

Viewing Test Suite Details

The Test Suite Details page shows all tests of the suite along with their status and duration.

To open the Test Suite Details page:
  1. Open the Test Results page.
  2. Click the All Tests toggle button.
  3. Click the suite name link in the Suite Name column.
The Test Suite Details page shows the following information.
Element Description

Suite Name

Shows the name of the test suite.

Test Name

Displays the name of the test. Click the link to open the details page of the test.

Duration

Displays the total duration of the test.

Status

Displays the test status as Passed or Failed.

Viewing Test Details

The Test Details page shows the test result, parent suite name, status, and duration.

To open the test details page:
  1. Open the Test Results page.
  2. Click the All Failed Tests toggle button and the click the test name link in the Test Name column.
    You can also click the All Tests toggle button, open the test suite details page, and then click the test name link in the Test Name column.
The Test Details page shows the following information.
Element Description

Suite Name

Shows the name of the parent test suite.

Test Name

Displays the name of the test.

Status

Displays the test status as Passed or Failed.

Duration

Displays the total duration of the test.

Failed Image

If the test failed, click the image to download it. The image file name is same as the test name followed by —failed.

Error Message

If the test failed, expand the field to see the error message.

Stack Trace

If the test failed, expand to see the stack trace report.

Viewing a Build’s Git Polling Log

If you have configured the build to run on a SCM polling schedule, you can view the Git polling log in Build details page.

To configure Git SCM polling for a build, see Configuring Build Triggers.
To view the Git polling log of a build:
  1. In the navigation bar, click Build.
  2. In the Jobs Overview page, click the job name.
  3. In the Build History table, click the build number link.
  4. Click the Git Logs icon.
The Git build logs page shows the polling log.

Tip:

In the Job Details page of a job, click the Git Logs icon to view the Git polling log of the last build.

Viewing a Job’s User Action History

You can use the Audit log to track the user actions on a build. Use the log to see who performed particular actions on the job. For example, you can see who cancelled a build of the job, or who disabled the job and when was it disabled.

To view the Audit log of a job:
  1. In the navigation bar, click Build.
  2. In the Jobs Overview page, click the job name.
  3. In the Job Details page, click the Audit icon.
The Audit log page tracks and displays the username and date-time stamp of the following actions performed on a job:
  • Who created the job

  • Who started a build or how a build was triggered (followed by the build number), when the build succeeded or failed, and the duration of the build

    A build can also be triggered by a timer, a commit to a Git repository, or an upstream job.

  • Who aborted a build

  • Who changed the configuration of the job

  • Who disabled a job

  • Who enabled a job

Monitoring Jobs and Builds from IDEs

You can monitor jobs and builds from IDEs such as OEPE, NetBeans IDE, and JDeveloper.

See following topics for more information:

Using the WebLogic Maven Plugin

The WebLogic server includes a Maven plugin that you can use to perform various deployment operations against the server, such as deploy, redeploy, and update. The plugin is available in the Oracle Developer Cloud Service build executor.

To install and invoke the WebLogic Maven plugin from a project build job:
  1. Install the WebLogic Maven plugin (weblogic-maven-plugin.jar) into the Maven repository.
    As the Maven repository is always empty when a jobs starts, configure the job to install the plugin.
    1. Open the job in Oracle Developer Cloud Service.

    2. Click Configure.

    3. Expand Build, click Build Step, and select Execute Shell.

    4. Enter the following command in Command:

      mvn install:install-file -Dfile=$WLS_HOME/server/lib/weblogic-maven-plugin.jar -DpomFile=$WLS_HOME/server/lib/pom.xml

    5. Click Save.

  2. Invoke the WebLogic Maven plugin from your application’s pom.xml file.
    For example, add the following command in the pom.xml file to invoke the deploy operation:

    mvn com.oracle.weblogic:weblogic-maven-plugin:deploy

For more information about how to use the WebLogic Maven plugin, see Fusion Middleware Deploying Applications to Oracle WebLogic Server in Oracle Fusion Middleware Online Documentation Library.

Disabling a Job

You can disable a job from the Job Details page.

When disabled, you cannot run builds of the job. All automatic configured builds are also disabled.
To disable a job:
  1. In the navigation bar, click Build.
  2. In the Jobs table, click the job name link.
  3. Click the Disable button.

Deleting a Job

You can delete a job from the Job Details page.

When deleted, all builds and deployment artifacts of the job are also deleted.
To delete a job:
  1. In the navigation bar, click Build.
  2. In the Jobs table, click the job name link.
  3. Click the Delete button.
  4. In the Delete Job dialog, select I understand that this job will be permanently deleted check box and click Delete.