Configure and Run Project Jobs and Builds

Oracle Developer Cloud Service (DevCS) includes continuous integration services to build project source files. You can configure the builds from the Builds page.

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

What is a Job and a Build?

A Job is a configuration that defines the builds of your application. A Build is a result of a job’s run.

A job defines where to find the source code files, how and when to run builds, the software and the environment required to run builds. When a build runs, it creates packaged archives of the application that you can deploy to a web server. A job can have hundreds of builds. Each build would’ve its artifacts, logs, and reports.

Build Concepts and Terms

Here are some terms that this documentation uses to describe the build features and components.

Term	Description
Build System	Software that automates the process of compiling, linking and packaging the source code into an executable form.
Build executor	A basic block that enables a build to run. Each build uses one build executor.
Workspace	A temporary directory used by the build executor to download source code files and generate artifacts when a build runs.
Build artifact	A file generated by a build. It could be a packaged archive file, such as a .zip or .ear file, that you can deploy to a build server.
Trigger	A condition to run a build.

Create and Manage Jobs

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

Action	How To
Create a blank job	On the Build page, click + Create Job. In the New Job dialog box, enter a unique name and description. Select Create a free-style job. Click Save.
Copy an existing job	At times, you may want to copy parameters and configuration of a job to another. You can do that when you create a job. You can’t copy the configuration of an existing job to another existing job. On the Build page, click + Create Job. In the New Job dialog box, enter a unique name and description. Select Copy existing job. From the Select a Job drop-down list, select the source job. Click Save. After you create the new job, you can change the copied parameters and configuration. Note that the job is disabled by default to prevent it from running any scheduled build while you are configuring the job. To run builds of the copied job, you must enable it manually.
Configure a job	The job configuration page opens immediately after you create a job. You can also open it from the Jobs tab. From the jobs list, click the job name, and then click Configure.
Run a build of a job	From the jobs list, click Build Now .
Delete a job	From the jobs list, click the job name, and then click Delete.

Configure a Job

You can create, manage, and configure jobs from the of the Builds page.

To open a job’s configuration page, in the Builds page, click the job’s name. In the job’s details page, click Configure.

Access Project Git Repositories

You can configure a job to access project’s Git repositories and their source code files.

1. Open the Configure Build Job page of the job.
2. Click the Source Control tab.
3. Select the Git option.
4. In Repository, select the Git repository.
5. To specify a branch other than the default branch, in Branches, click Add and select the branch in Branch Specifier.

   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.

6. Click Save.

Trigger a Build Automatically on SCM Commit

You can configure a job to monitor its Git repositories and trigger a build automatically after a commit is pushed to the Git repository.

1. Open the job’s configuration page.

2. Click the Triggers tab.

3. Select the Based on SCM polling schedule check box.

4. To specify a list of files and directories to track for changes in the repository, in the Source Control tab, expand Advanced Git Settings, and enter the list in Included Region. You can use a regular expressions to specify files.

   You must separate each entry by a new line. An empty list implies that all files and directories must be tracked.

   For example, this list configures the job to trigger a build when a user adds or updates an .html, .jpeg, or .gif file in the myapp/src/main/web/ directory of the specified Git repository.

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

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

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

5. To specify a list of files and directories not to track for changes in the repository, in the Source Controltab, expand Advanced Git Settings, and enter the list in Excluded Region. You can use a regular expressions to specify files.

   You must separate each entry by a new line. An empty list implies that all files and directories must be tracked. If a change occurs in any of the specified files or directories, a build won’t run. If there is an overlap between included and excluded regions, exclusions take precedence over inclusion.

6. To exclude users whose commits to the repository don’t trigger builds, in Excluded User, enter the list of user names.

7. Click Save.

Trigger a Build Automatically on SCM Polling

SCM polling enables you to configure a job to periodically check the job’s Git repositories for any commits pushed since the job’s last build. If updates are found, it triggers a build. You can configure the job and specify the schedule in Coordinated Universal Time (UTC). UTC is the primary time standard by which the world regulates clocks and time.

1. Open the job’s configuration page.

2. Click the Triggers tab.

3. Select the Based on SCM polling schedule check box.

4. In Schedule, specify the schedule using Cron expressions.

5. To not to run a build on every push to the project Git repository, select the Do not poll on SCM change check box. The builds now run only on the specified schedule.

6. Click Save.

To see the SCM poll log of the job after the build runs, in the job's details page or the build's details page, click SCM Poll Log .

Generate Cron Expressions

You can use Cron expressions to define periodic build patterns.

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

You can specify the Cron 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 (1-7)

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 0/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

Access Files of a Git Repository's Private Branch

To access a Git repository's private branch, configure the job to use SSH.

1. On the computer that you'll use to access the Git repository, generate a SSH key pair and upload its private key to DevCS. See Upload Your Public SSH Key. Make sure that the private key on your computer is accessible to the Git client.
   Ignore this step if you've already uploaded the SSH public key.
2. Copy the Git repository’s SSH URL.

   On the Git page, from the Repositories drop-down list, select the Git repository. From the Clone drop-down list, click Copy to clipboard to copy the SSH URL.

   
   Description of the illustration devcs_code_clone.png
3. Open the job’s configuration page.
4. Click Configure , if necessary.
5. Click the Git tab.
6. From the Add Git list, select Git.
7. In Repository, paste the SSH URL of the Git repository.
8. In Branch, select the private branch.
9. Click the Before Build tab.
10. Click Add Before Build Action and select SSH Configuration.
11. In Private Key and Public Key, enter the private and the public key of your SSH Private-Public key pair.
    Leave the Public Key empty to use fingerprint.
12. In Pass Phrase, enter the pass phrase of your SSH Private-Public key pair. Leave it empty if the keys aren’t encrypted with a pass phrase.
13. Continue to configure the job, as desired.
14. Click Save.

Publish Git Artifacts to a Git Repository

Git artifacts, such as tags, branches, and merge results can be published to a Git repository as a post-build action.

1. Open the job’s configuration page.
2. In the Source Control tab, add the Git repository where you want to publish Git artifacts.
3. Click the Post Build tab.
4. Select the Git Publisher check box.
5. To push Git artifacts to the Git repository only if the build succeeds, select the Publish only if build succeeds check box.
6. To push merges back to the target remote name, select the Merge results check box.
7. To push a tag to the remote repository, in Tag to push, click Add and specify the Git repository tag name. You can also use environment variables. In Target remote name, specify the target remote name of the Git repository where the tag is pushed. By default, origin is used.

   The push fails if the tag doesn’t exist. Select the Create new tag check box to create the tag and enter a unique tag name.

8. To push a branch to the remote repository, in Branch to push, click Add and specify the Git repository branch name. You can also use environment variables. In Target remote name, specify the target remote name of the Git repository where the branch is pushed. By default, origin is used.
9. Click Save.

Advanced Git Options

When you configure the Git repositories of a job, you can also configure the job with some advanced Git options, such as change the remote name of the repository, set the checkout directory in the workspace, and whether to clean the workspace before a build runs.

Use these fields of the Source Control tab of the job's configuration to set advanced settings.

Advanced Repository Settings

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.

Advanced Git Settings

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.

View Changes Log

The Change log displays the files that were added, edited, or removed from the job’s Git repositories before the build was triggered.

You can view the SCM changes log from the job’s details page and a build’s details page. The Recent Changes page that you open from the job’s details page displays SCM commits from last 20 builds in the reverse order. The Changes page that you open from a build’s details page displays SCM commits that happened after the previous build.

The log shows build ID, commit messages, commit IDs, and affected files.

Trigger a Build Automatically on a Schedule

You can configure a job to run builds on a specified schedule specified in Coordinated Universal Time (UTC). UTC is the primary time standard by which the world regulates clocks and time.

1. Open the job’s configuration page.

2. Click the Triggers tab.

3. Select the Based on this schedule check box.

4. In Schedule, specify the schedule using Cron expressions.

5. Click Save.

Use Build Parameters

Using build parameters, you can pass additional information when a build runs that is not available at the time of job configuration.

You can configure a job to use a parameter and its value as an environment variable or through variable substitution in other parts of the job configuration. When a build runs, a Configure Parameters dialog box opens so you can enter or change the default values of the 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. From the Add Parameter drop-down list, select the parameter type.
5. Enter values such as name, default value, and description.
6. Click Save.

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.

Access the Oracle Maven Repository

The Oracle Maven Repository contains artifacts, such as ADF libraries, provided by Oracle. You may require these artifacts to compile, test, package, perform integration testing, or deploy your applications. For more information about the Oracle Maven repository, see https://maven.oracle.com/doc.html.

To build your applications and access the Oracle Maven Repository, you configure the job and provide your credentials to access the repository.

1. 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.

2. Configure the POM file and add the Oracle Maven Repository details.

   1. Add a <repository> element to refer to https://maven.oracle.com.

      Example:

      <repositories>
        <repository>
          <name>OracleMaven</name>
          <id>maven.oracle.com</id>
          <url>https://maven.oracle.com</url>
        </repository>
      </repositories>
      

      Depending on your application, you may also want to add the <pluginRepository> element to refer to https://maven.oracle.com.

      Example:

      <pluginRepositories>
        <pluginRepository>
          <name>OracleMaven</name>
          <id>maven.oracle.com</id>
          <url>https://maven.oracle.com</url>
        </pluginRepository>
      </pluginRepositories>

   2. Commit the POM file to the project Git repository.

3. If you’re a project owner, set up Oracle Maven Repository connections for the project’s team members.

4. Create and configure a job to access Oracle Maven Repository.

Configure a Job to Connect to the Oracle Maven Repository

1. Open the Environment tab.
2. Select the Connect Oracle Maven Repository check box.

   The following table highlights what options you can set for the Oracle Maven Repository.

   Element	Description
   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.

3. Click Save.

Run UNIX Shell Commands

You can configure a job to run a shell script or commands when a build runs.

1. Open the job’s configuration page.

2. Click the Build Steps tab.

3. From Add Build Step, select Execute Shell.

4. In Command, enter the shell script or commands.

   The script runs with the workspace as the current directory. If there is no header line, such as #!/bin/sh specified in the shell script, then the system shell is used. You can also use the header line to write a script in another language, such as Perl (#!/bin/perl) or control the options that shell uses.

   By default, when a build runs, it invokes the shell with the -ex option. It prints all commands before they run. The build failsif any of the commands exits with a non-zero exit code. You can change this behavior by adding the #!/bin/... line.

   Tip:

   Don’t enter a long shell script. For a long script, create a script file and add it in the Git repository. You can run the script with a command (such as bash -ex /myfolder/myscript.sh).

5. Click Save.

Build Maven Applications

Using Apache Maven, you can automate your build process and download dependencies, as defined in the POM file.

1. Upload the Maven POM files to the project Git repository.
2. Open the job’s configuration page.
3. In the Source Controltab, add the Git repository where you uploaded the build files.
4. Click the Build Steps tab.
5. From Add Build Step, select Invoke Maven 2 or Invoke Maven 3.

   The following table lists the fields of the Maven section.

   Element	Description
   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.

6. Click Save.

Use 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 DevCS build executor.

When a build runs, the build executor creates an empty Maven repository in the workspace. To install the WebLogic plugin every time a build starts, in the job configuration, add a shell command to install the plugin and then deploy it.

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.

1. Open the job’s configuration page.

2. Click the Build Steps tab.

3. From Add Build Step, select Execute Shell.

4. In Command, enter this command.

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

5. Click Save.

Upload to or Download Artifacts from the Project Maven Repository

To upload artifacts to the Maven repository, you'll use the distributionManagement snippet in the POM file. To download artifacts from the Maven repository, use the repositories snippet in the POM file.

1. To upload a build artifact to the Maven repository, copy the distributionManagement snippet of the project’s Maven repository and add it to the POM file.
   1. In the navigation bar, click Maven .
   2. On the right side of the page, click Browse.
   3. In the Artifact Details section, expand Distribution Management.
   4. In the Maven tab, click Copy to copy the <distributionManagement> code snippet to the clipboard.
   5. Open the POM file of your project in a code editor (or a text editor) and paste the contents of the clipboard under the <project> element.

      Example:

      
      Description of the illustration devcs_maven_snippet.png

2. To download an artifact from the Maven repository, use the repositories snippet of the project’s Maven repository.
   1. In the navigation bar, click Maven .
   2. On the right side of the page, click Browse.
   3. In the Artifact Details section, expand Distribution Management.
   4. In the Maven tab, copy the <repository> element of the Distribution Management to the clipboard.
   5. Open the POM file of your project in a code editor (or a text editor) and paste the <repository> element in the<repositories> element under <project>.
      Example:

      <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
      	<modelVersion>4.0.0</modelVersion>
      	<groupId>com.example.employees</groupId>
      	<artifactId>employees-app</artifactId>
      	<packaging>war</packaging>
      	<version>0.0.1-SNAPSHOT</version>
      	<name>employees-app Maven Webapp</name>
      	<url>http://maven.apache.org</url>
      	
      	<repositories>
      	  <repository>
                 <id>Demo_repo</id>
                 <name>Demo Maven Repository</name>
                 <url>http://developer.us2.oraclecloud.com/profile/my-org/s/my-org_demo_12345/maven/</url>
               </repository>
      	</repositories>
      .
      .
      .
      </project>

3. Save the file, commit it to the Git repository, and then push the commit.
4. Configure the job to add a Maven step and add the required Maven goals.

   Tip:

   Use the deploy goal to upload Maven artifacts to the project’s Maven repository.

5. Run a build of the job.
6. If you configured the job to upload artifacts to the project’s Maven repository, after the build is successful, verify the artifacts in the Maven page.

   Example:

   
   Description of the illustration devcs_maven_artifacts.png

Note that the credentials in settings.xml aren’t required to access the project’s Maven repository when running a build. The Build job has full access to the project’s Maven repository for uploads and downloads.

Build Ant Applications

Using Apache Ant, you can automate your build processes as described in its build files. For more information, see https://ant.apache.org/.

1. Upload the Ant build files (such as build.xml and build.properties) to the project Git repository.

2. Open the job’s configuration page.

3. In the Source Controltab, add the Git repository where you uploaded the build files.

4. Click the Build Steps tab.

5. From Add Build Step, select Invoke Ant .

6. In Targets, specify the Ant targets or leave it empty to run the default Ant target specified in the build file.

7. InBuild File, specify the path of the build file.

8. If necessary, in Properties, specify the values for properties used in the Ant build file.

   Example:

   # comment
   name1=value1
   name2=$VAR2

   When a build runs, these are passed to Ant as -Dname1=value1 -Dname2=value2. You should always use $VAR for parameter references (don’t use%VAR%). Use \\to escape a \ and avoid using double-quotes ("). To define an empty property, use varname=in the script.

9. If your build requires a custom ANT_OPTS, specify it in Java Options. You may use it to specify Java memory limits (example: -Xmx512m). Don’t specify other Ant options here (such as -lib), but specify them in Targets.

10. Click Save.

Build Gradle Applications

Using Gradle, you can automate your build processes as defined in its build script. For more information about Gradle, see https://gradle.org/.

In DevCS, Gradle 5 is available. To use another version of Gradle, use Gradle Wrapper in the Gradle build step. Gradle recommends using Gradle Wrapper as the preferred way to run a Gradle build. To learn more about using Gradle Wrapper, see https://docs.gradle.org/current/userguide/gradle_wrapper.html.

Configure a Job to Run Gradle Commands

1. Upload the build.gradle file to the project Git repository.

2. Open the job’s configuration page.

3. Click the Build Steps tab.

4. From Add Build Step, select Invoke Gradle.

5. To invoke the default Gradle script, select Invoke Gradle. From Gradle Version, select the Gradle version.

   To use Gradle wrapper script, select Use Gradle Wrapper. If you want to use the gradlew command as an executable command, select the Make gradlew executable check box. To use the gradlew command from the root build script directory, select the From Root Build Script Dir check box.

6. In Build step description, enter a description.

7. In Switches, enter Gradle switches.

8. In Tasks, enter Gradle tasks.

9. In Root Build Script, enter the path and directory name of the top-level build.gradle file if it’s available in a directory other than the module root directory. The path must be relative to the root directory.

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

10. In Build File, enter the name and path of the Gradle build.gradle file.

11. If you are using a multi-executor slave, select the Force GRADLE_USER_HOME to use workspace 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.

12. Click Save.

Build Node.js Applications

Using Node.js, you can develop applications that run JavaScript on a server. For more information, see https://nodejs.org.

Configure a Job to Build a Node.js Application

1. Open the job’s configuration page.

2. In the Source Control tab, add the Git repository where you uploaded the script file.

3. Click the Environment tab.

4. Select the Use NodeJS Version check box.

5. From NodeJS Installation, select the Node.js version.

6. Click the Build Steps tab.

7. From Add Build Step, select Invoke NodeJS.

8. In Script, enter the script.

9. Click Save.

Access an Oracle Database Using SQLcl

Using SQLcl, you can run SQL statements from a build to connect and access an Oracle Database. You can use SQLcl to access any Oracle Database available on public internet that you can connect to using a JDBC connect string. You can run DML, DDL, and SQL Plus statements. You can also use SQLcl in a test scenario and run SQL scripts to initialize seed data or validate database changes.

SQLcl requires Java SE 1.8 or later. To learn more about SQLcl, see http://www.oracle.com/technetwork/developer-tools/sqlcl/overview/index.html. Also see Using the help command in SQLcl in Using Oracle Database Exadata Express Cloud Service and the SQL Developer Command-Line Quick Reference documentation to know more about using SQLcl supported commands.

To connect to Oracle Database Exadata Express Cloud Service, download the ZIP file that contains its credentials and upload it to the job’s Git repository. You can download the ZIP file from the Oracle Database Cloud Service service console. See Downloading Client Credentials in Using Oracle Database Exadata Express Cloud Service.

Configure a Job to Run SQLcl Commands

Before you configure the job, note these points:

• DevCS doesn’t support SQL commands to edit buffer (such as set sqlformat csv) or edit console.
• DevCS doesn’t support build parameters in the SQL file.
• If you are using Oracle REST Data Services (ORDS), some SQLcl commands, such as the BRIDGE command, requires a JDBC URL.

  Example: BRIDGE table1 as "jdbc:oracle:thin:DEMO/demo@http://examplehost.com/ords/demo"(select * from DUAL);

• To mark a build as failed if the SQL commands fail, add the WHENEVER SQLERROR EXIT 1 line to your script.

1. Open the job’s configuration page.

2. Click the Main tab.

3. From the JDK drop-down list, select JDK 8, or later.

4. Click the Build Steps tab.

5. From Add Build Step, select SQLcl Builder.

6. In Username and Password, enter the user name and password of the Oracle Database account.

7. In Credentials File, enter the workspace path of the uploaded credentials zip file.

8. In Connect String, enter the JDBC or HTTP connection string of the Oracle Database account using any of the host_name:port:SID or host_name:port/service_name formats.

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

   HTTP Example: http://test_server.oracle.com:8085/ords/demo

9. In 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.

10. If you selected SQL File in Source, then in SQL File Path, enter the path of the SQL file in the Git repository. You can copy the file’s path from the Code page.

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

12. In Role, elect the database role of the user. By default, it is set to Default.

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

14. Click Save.

When a build runs, DevCS stores your Oracle Database credentials in the Oracle Wallet. Check the build’s log for the SQL output or errors.

Run Oracle PaaS Service Manager Commands Using PSMcli

Using Oracle PaaS Service Manager command line interface (PSMcli) commands, you can create and manage the lifecycle of various services in Oracle Public Cloud. You can create service instances, start or stop instances, or remove instances when a build runs.

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.

Configure a Job to Run PSMcli Commands

1. Open the job’s configuration page.

2. Click the Build Steps tab.

3. From Add Build Step, select Invoke PSMcli.

4. In Username and Password, enter the user name and password of the Oracle Cloud account.

5. In Identity Domain, enter the identity domain.

6. In Region, select your identity domain’s region.

7. In Output Format, select the preferred output format: JSON (default) or HTML.

8. From Add Build Step, select Execute Shell.

9. In Command, enter the PSM commands on separate lines.

10. Click Save.

You can add multiple shell steps to run different group of commands. Don’t add the PSMcli build step again.

Publish JUnit Results

If you use JUnit in your application to run test scripts, you can configure your job to publish JUnit test reports and get useful information about test results, such as historical test result trends, failure tracking, and so on.

1. Upload your application with test script files to the Git repository.

2. Open the job’s configuration page.

3. Click the Post Build tab.

4. Select the Publish JUnit test result report check box.

5. In Test Report XMLs, specify the path and names of XML files to include.

   If you are using Ant, specify the path such as **/build/test-reports/*.xml. If you are using Maven, specify the path such as target/surefire-reports/*.xml. Make sure that you don’t include any non-report files into this pattern.

6. To see and retain the standard output and errors in the build log, select the Retain long standard output/error check box.

   If you don’t select the check box, the build log is saved, but the build executor truncates it to save space. If you select the check box, every log message is saved, but this might increase memory consumption and can slow the performance of the build executor.

7. To combine all test results into a single table of results, select the Organize test output by parent location check box.

   If you use multiple browsers, then the build executor categorizes results by browsers.

8. Click Save.

After a build runs, you can view its test result.

View Test Results

You can view the JUnit test results of a build from the Test Results page.

Action	How To
View test results of the last build	Open the job’s details page. Click .
View test results of a particular build	Open the job’s details page. In the Build History table, click the build number. Click .
View test suite details	On the Test Results page, click the All Tests toggle button. From the Suite Name, click the suite name.
View details of a test	Open the test suite details page and click the test name. To view details of a failed test, on the Test Results page, click the All Failed Tests toggle button, and then click the test name.
View test results history	On the Test Results page, click View Test Results History.

If you configure the job to archive videos and image files, click Show to download the test image and click Watch to download the test video file.

The supported image formats are .png, .jpg, .gif, .tif, .tiff, .bmp, .ai, .psd, .svg, .img, .jpeg, .ico, .eps, and .ps.

The supported video formats are .mp4, .mov, .avi, .webm, .flv, .mpg, .gif, .wmv, .rm, .asf, .swf, .avchd, and .m4v.

Use the Xvfb Wrapper

Xvfb is an X server that implements the X11 display server protocol and can run on machines with no physical input devices or display.

Configure a Job to Run Xvfb

1. Open the Build Environment tab.

2. Click Add Build Environment and select Xvfb Wrapper.

   The following table highlights what options you can set for the Xvfb Wrapper.

   Element	Description
   Display Number	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.
   Screen offset	Specify the offset for display numbers. The default value is 0.
   Screen Size (WxHxD)	Specify the resolution and color depth of the created virtual frame buffer in the WxHxD format. The default value is 1024x758x24.
   Additional options	Specify any additional Xvfb command line options. The default options are -nolisten inet6 +extension RANDR -fp /usr/share/X11/fonts/misc.
   Timeout in seconds	Specify the timeout duration for the build to wait before returning control to the job. The default value is 0.
   Log Xvfb output	The check box is selected by default to redirect the output of Xvfb to the job log. Deselect the check box if you do not want to redirect the output.
   Shutdown Xvfb with whole job, not just with the main build action	The check box is selected by default to keep the Xvfb server running for post-build steps. Deselect the check box if you do not want to keep the server running.

3. Click Save.

Publish Javadoc

If your application source code files are configured to generate Javadoc, then you can configure a job to publish Javadocs when a build runs.

1. Open the job’s configuration page.

2. Click the Post Build tab.

3. Select the Archive the Artifacts check box.

4. In Files to archive, enter space or comma separated list of files (with path) to archive. You can use wildcards too. Example: module/dist/**/*.zip.

   To enable automatic validation for file masks, select the Enable auto validation for file masks check box.

5. In Excludes, enter space or comma separated list of files (with path) to exclude.

   A file that matches the exclude pattern isn’t archived even if it matches the pattern specified in Files to archive.

6. To discard artifacts from older builds and save artifacts from the last stable build, select the Discard all but the last successful/stable artifact to save disk space check box. Artifacts from the last unstable build or last failed build are also saved if they are newer than the last stable build.

7. From Compression Type, select the archive format.

8. If your application is a Maven application and you want to archive Maven artifacts, select the Archive Maven 3 Artifacts check box.

   To archive the Maven POM file along with Maven artifacts, select the Include generated POMs check box. To retain the most recent artifacts, select the Discard old artifacts check box.

9. Click Save.

Archive Artifacts

If you want builds of a job to archive artifacts, you can do so as a after build action. Once archived, you can download the artifacts manually and deploy them. By default, artifacts of a build are kept as long as the build log is kept.

1. Open the job’s configuration page.

2. Click the Post Build tab.

3. Select the Archive the Artifacts check box.

4. In Files to archive, enter space or comma separated list of files (with path) to archive. You can use wildcards too. Example: module/dist/**/*.zip.

   To enable automatic validation for file masks, select the Enable auto validation for file masks check box.

5. In Excludes, enter space or comma separated list of files (with path) to exclude.

   A file that matches the exclude pattern isn’t archived even if it matches the pattern specified in Files to archive.

6. To discard artifacts from older builds and save artifacts from the last stable build, select the Discard all but the last successful/stable artifact to save disk space check box. Artifacts from the last unstable build or last failed build are also saved if they are newer than the last stable build.

7. From Compression Type, select the archive format.

8. If your application is a Maven application and you want to archive Maven artifacts, select the Archive Maven 3 Artifacts check box.

   To archive the Maven POM file along with Maven artifacts, select the Include generated POMs check box. To retain the most recent artifacts, select the Discard old artifacts check box.

9. Click Save.

Discard Old Builds and Artifacts

To save storage space, you can configure a job to discard its old builds and artifacts. The old builds are discarded after the job configuration is saved and after a job is built.

1. Open the job’s configuration page.

2. Select the Main tab.

3. Configure the discard options.

4. Click Save.

Copy Artifacts from Another Job

If your application depends on another job’s artifacts, you can configure the job to copy those artifacts when a build runs.

1. Open the job’s configuration page.

2. Click the Build Steps tab.

3. Click Add Build Step and select Copy Artifacts from Another Job.

4. In Job Name, select the job whose artifacts you want to copy.

5. In Which Build, select the build that generated the artifacts.

6. In Artifacts to copy, specify the artifacts to copy. When a build runs, the artifacts are copied with their relative paths.

   If no value is specified, the build copies all artifacts. Note that the archive.zip file is never copied.

7. In Target Directory, specify the target directory in the workspace where the artifacts are copied.

8. To flatten the directory structure of copied artifacts, select the Flatten Directories check box.

9. By default, if a build can’t copy artifacts, it is marked as failed. If you don’t want the build to be marked as failed, select the Optional (Do not fail build if artifacts copy failed) check box.

10. Click Save.

Configure General and Advanced Job Settings

You can configure several general and advanced job settings, such as name and description, the JDK version used in the build, discarding old builds, running concurrent builds, adding timestamps to the build log, and more.

Action	How To
Update the job’s name and description	Open the job’s configuration page. Click the Main tab. In Name and Description, update the job name and description. Click Save.
Run concurrent builds	By default, DevCS runs one build of a job at a time. The next build runs after the running build finishes. To configure the job to run concurrent builds, do this: Open the job’s configuration page. Click the Main tab. Select the Execute concurrent builds if necessary check box. Click Save.
Set a quiet period	You can specify a period (in seconds) before a new scheduled build of the job should wait before it runs. If the build server is busy with too many builds, setting a longer quiet period can reduce the number of builds. Open the job’s configuration page. Click the Advanced tab. Select the Quiet period check box and specify the value in seconds. Click Save.
Set a retry count	If the builds of a job fail, by default, the build executor tries five times to run the build. You can increase or decrease the count. Open the job’s configuration page. Click the Advanced tab. Select the Retry Count check box. In SCM Checkout specify the number of times the build executor tries the build to checkout files from the Git repository. Click Save.
Abort a build if it’s stuck for some duration	Open the job’s configuration page. Click the Environment tab. Select the Abort the build if it is stuck check box. In Timeout Minutes, specify the duration. If a build doesn’t complete in the specified amount of time, the build is terminated automatically and marked as aborted. Select the Fail the build check box to mark the build as failed, rather than aborted. Click Save.
Add timestamps to the build log	By default, build logs are not timestamped, however you can configure a job to add them to the log. Open the job’s configuration page. Click the Environment tab. Select the Add Timestamps to the Console Output check box. Click Save.

Change a Job's JDK Version

1. Open the job’s configuration page.
2. Click Settings .
3. Click the Software tab.
4. In Available Software, from the Java drop-down list, change the JDK's version number.
   You can also select GraalVM instead of selecting JDK. GraalVM is a universal virtual machine for running applications written in JavaScript, Python, Ruby, R, JVM-based languages like Java, Scala, Groovy, Kotlin, Clojure, and LLVM-based languages such as C and C++. To learn more, see https://www.graalvm.org/docs/.
5. Click Save.

Run a Build

You can run a job’s build manually or configure the job to trigger it automatically on an SCM commit or according to a schedule.

Action	How To
Run a build manually	Open the job’s details page and click Build Now. You can also run a job’s build from the Jobs Overview page. In the jobs table, click Build Now .
Run a build on SCM commit	See Trigger a Build Automatically on SCM Commit.
Run a build on a schedule	See Trigger a Build Automatically on a Schedule.

View a Job’s Builds and Reports

To view a job’s builds, reports, build history and perform actions such as run a build or configure the job, on the Build page, click the job name to open its details page.

View a Build’s Logs and Reports

A build generates various types of reports and logs such as SCM Changes, test results, and action history. You can open these reports from the Job Details page or the Build Details page.

The following table lists the various types of reports generated by a build. On the Job Details page or the Build Details page, click the report icon to view its details.

Log/Report	Description
Build Log	View the last build’s log. In the log 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.
SCM Changes	View all files that have changed in the build. When a build is triggered, the build system checks the job’s Git repositories for any changes to the SCM. If there are any updates, the SCM Change log displays the files that were added, edited or removed.
SCM Poll Log	View the Git SCM polling log of the builds that displays the log of builds triggered by SCM polling. The log includes scheduled uilds and builds triggered by SCM updates. In the Job Details page of a job, click Latest SCM Poll Log to view the Git SCM polling log of the last build.
Test Results	View the log of build’s JUnit test results. To open the Test Suite details page, on the Test Results page, click the All Tests toggle button and click the suite name in the Suite Name column. To view details of a test, on the Test Results page, click the All Failed Tests toggle button and then 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.
Audit	View the Audit log of user actions. 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.

View a Project’s Build History

The Build History page displays builds of all jobs of the project.

To view the build history, in the Build Queue box of the Builds page, click the View Recent Build History link. The history page shows the last 50 builds of the project. Click a job name to open its details page. Click a build number to open its details page. Click to open the build’s console and view the console log output.

Tip:

To sort the table data by a column, right-click inside the build history table column and select the sort order from the Sort context menu.

View a Job’s Build History

A job’s build history can be viewed in the Build history section of the Job Details page. It 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.

The build history shows information abut how the build was triggered, its status, build number, date-time stamp, a Console icon to open the build’s console, and a Delete icon to delete the build.

To review the build history, note these points:

• In the Build column, an * in the build number indicates the build is annotated with a description. Mouse over the build number to see the description.

• The list doesn’t show the discarded and deleted jobs.

• 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.

• To sort the table data in ascending or descending order, click the header column name and then click the Previous or Next icon in the column header.

  You can also right-click inside table column and then select the sort order from the Sort context menu.

• A project non-member can’t delete a build.

View a Job’s User Action History

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

To open the Audit log, from the job’s details page, click Audit .

The log displays information about these user actions:

• 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

View a Build’s Details

To open the a build’s details page, click the build number in the Build History.

A build’s details page shows its status, links to open build reports, download artifacts, and logs. You can perform these common actions from a build’s details page.

Action	How To
Keep a build forever	A build that’s marked as ‘forever’ isn’t removed if a job is configured to discard old builds automatically. You can’t delete it either. To keep a build forever, click Configure, select the Keep Build Forever check box, and click Save.
Add a name and description to a build	Adding a description and a name is especially helpful if you mark a particular build to keep it forever and not get discarded automatically. When you add a description to a build, an * is added to the build number in the Build History table. To keep a build forever, click Configure. In Name and Description, enter the details, and click Save.
Open a build’s log	Click Build Log.
Delete a build	Click Delete.

Download Build Artifacts

If the job is configured to archive artifacts, you can download them to your computer and then deploy to your web server.

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.

1. Open the job’s details page.

2. Click Latest Artifacts.

   To download artifacts of a particular build, n the Build History, click the build number, and then click Build Artifacts.

3. Expand the directory structure and click the artifact link (file or directory) to download it.

   To download a zip file of all artifacts, click All files in a zip.

4. Save the file to your computer.

Watch a Job

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

To get email notifications, enable them in your user preferences, and then set up a watch on the job.

Action	How To
Enable your email notifications preference	In your user preferences page, select the Build Activities check box.
Watch a job	Open the job’s details page. Click the On toggle button, if necessary. Click CC Me. In the CC Me dialog box, to receive email when the build is successful, select the Successful Builds check box. Select Failed Builds to receive email when the build fails. Click OK.
Disable email notifications of the job to all subscribed members	Open the job’s details page. Click the Off toggle button, if necessary.

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 build executor.

To use a variable, use the $VARIABLE_NAME syntax. Example: $BUILD_ID.

Common Variables

This 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.
BUILD_DIR	The build output 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.
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.
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.
PATH	The PATH variable set in the build executor specifying the path of executables in the build executor.
WORKSPACE	The absolute path of the build executor's workspace.

Software Variables

Environment Variable	Description
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.
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.
HUDSON_HOME	The path of the Hudson home directory.
HUDSON_URL	The full URL of the Hudson server.
NODE_HOME	The path of the Node.js home directory.
NODE_PATH	The path of the Node.js modules directory.

To access JDeveloper or SOA, use these variables.

Software	Variables
JDeveloper	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=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper/cloud/oracle-javacloud-sdk/lib MIDDLEWARE_HOME_11_1_1_7_1=/opt/Oracle/Middleware_11.1.1.7.1 MIDDLEWARE_HOME_11G=/opt/Oracle/Middleware_11.1.1.7.1 MIDDLEWARE_HOME=/opt/Oracle/Middleware_11.1.1.7.1 ORACLE_HOME_11_1_1_7_1=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper ORACLE_HOME_11G=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper ORACLE_HOME=/opt/Oracle/Middleware_11.1.1.7.1/jdeveloper WLS_HOME_11_1_1_7_1=/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=/opt/Oracle/Middleware_11.1.1.7.1/wlserver_10.3
SOA	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 JAVACLOUD_HOME_SOA=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper/cloud/oracle-javacloud-sdk/lib JAVACLOUD_HOME_12C3=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper/cloud/oracle-javacloud-sdk/lib 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 MIDDLEWARE_HOME_SOA=/opt/Oracle/MiddlewareSOA_12.1.3 MIDDLEWARE_HOME_12C3=/opt/Oracle/MiddlewareSOA_12.1.3 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.1/jdeveloper ORACLE_HOME_SOA=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper ORACLE_HOME_12C3=/opt/Oracle/MiddlewareSOA_12.1.3/jdeveloper 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.1/wlserver WLS_HOME_SOA=/opt/Oracle/MiddlewareSOA_12.1.3/wlserver WLS_HOME_12C3=/opt/Oracle/MiddlewareSOA_12.1.3/wlserver

• Use JAVACLOUD_HOME variables to access the Java SDK
• Use ORACLE_HOME variables to access JDeveloper
• Use MIDDLEWARE_HOME variables to access Oracle Fusion Middleware. The MIDDLEWARE_HOME directory includes the JDeveloper installation directory, WebLogic Server installation directory, and the Oracle Common library dependencies.
• Use WLS_HOME variables to access the WebLogic server binary directory bundled with JDeveloper

Tip:

• You can run the env command as a Shell build step to view all environment variables of the build executor.

• Some Linux programs, such as curl, only support lower-case environment variables. Change the build steps in your job configuration to use lower-case environment variables.

  Example:

  export http_proxy="$HTTP_PROXY"
  export https_proxy="$HTTPS_PROXY"
  export no_proxy="$NO_PROXY"
  curl -v http://www.google.com

Software Installed on the Build Executor

Various software, such as JDeveloper, Xvfb, and Node.js, are installed on the build system and are available to the build executors when running on Oracle 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 step. You should use the PATH variable and other environment variables to access the installed software.

This table lists software available in the software catalog, in addition to the software installed by default.

Software	Version
Ant	1.9.6
Findbugs	3.0.1
Firefox	45.x
Git	1.7.1
Gradle	2.x 3.x 4.x
Java	10.x 9.x 1.8.x 1.7.x 1.6.x
Maven	3.3.3
Node.js	0.12.x 4.x 6.x 8.x
Node.js – grunt	0.4.5
Node.js – gulp	3.9.0
Node.js – grunt-cli	0.1.13
Node.js – gulp-cli	0.3.0
Node.js – bower	1.7.7
Node.js – oracledb	1.7
Node.js Driver for Oracle Database	12.1.0.2
Oracle ATG 11.1.0.1	11.1.0.1
Oracle Developer Studio 12.5	12.5
Oracle Instant Client 12c	12.1.0.2.0
Oracle JDeveloper 11g	11.1.1.7.1
Oracle SOA Suite 12c	12.2.1.1.0 12.1.3.0.0
SQLcl	17.4.0
Python	2.6.x
Python – pip3	8.1.x
Ruby	1.9.3p448
SFTP	yum:latest
Xvfb	1.15.0

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

Monitor Jobs and Builds from IDEs

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

See these topics for more information:

• Monitor a Project’s Builds in Eclipse IDE

• Monitor a Project’s Builds in NetBeans IDE

• Monitor a Project’s Builds in JDeveloper