Manage 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 Build page.

The Build page, also called as 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, and 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.

What is a Build VM and a Build VM Template?

A Build Virtual Machine (VM) is an OCI Compute Classic VM that runs build of jobs defined in the DevCS projects. A Build VM Template defines the operating system and the software installed on Build VMs.

When you configure a job to use a software, such as Node.js or Docker, you must create a Build VM template with the software and associate the job with that template. When a job’s build runs, it doesn’t run in DevCS, but on a VM of OCI Compute Classic.

To get started, you first create Build VM templates with different software that your organization members regularly use. After creating the templates, you allocate some Build VMs to each Build VM template. When your organization members create jobs, they associate the job with a Build VM template.

When a job’s build runs, a Build VM allocated for the job’s Build VM template starts. It first installs the software defined in the Build VM template. After installing the software, it clones the job’s Git repository (if configured) to the VM, and creates artifacts (again, if configured). After the build is complete, the artifacts are copied to the OCI Object Storage Classic container. The Build VM waits for some time for any queued builds. If no builds run in the wait time period, the Build VM stops. Each time the Build VM starts, the software are installed again and the first build of the VM would take more time to run.

Build Concepts and Terms

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

Term Description

Build System

A 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 a Build VM. Each build uses one build executor, or one Build VM.

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 method to run a build.

Set Up the Build System

Before your organization’s members can run builds, you must create Build VM templates and allocate Build VMs to those templates.

the organization administrator icon You must be the Organization Administrator to create and manage Build VM templates and Build VMs.

Create and Manage Build VM Templates

You can create and manage Build VM templates from the VM Templates page in Organization Administration.

Action How To

Create a Build VM template

  1. In the navigation bar, click Organization.

  2. Click VM Templates.

  3. In the Build VM Templates tab, click + New Template.

  4. In the New VM Template dialog box, enter a name and description of the VM template. In Platform, select the operating system to run on the VM.

  5. Click Create.

Configure a VM template’s software
  1. In the navigation bar, click Organization.

  2. Click VM Templates.

  3. In the Build VM Templates tab, select the template, and click Configure.

  4. If necessary, in Filter Software Packages, enter the search term and click the Search icon.

    To see the latest version of the software, select the Show latest versions only check box. This is helpful if multiple versions of the same software are available in the catalog.

  5. In the Software Catalog, click Add Add.

    If a software is dependent on another software, a message informs you about the dependencies that must be added along to use the software.

  6. Click Done.

Delete a VM template

  1. In the navigation bar, click Organization.

  2. Click VM Templates.

  3. In the Build VM Templates tab, select the template, and click Delete the Delete icon.

  4. In the Delete VM dialog box, click Yes to confirm.

Software Versions

Some software in the Software Catalog are available in multiple versions. For example, Gradle is available in Gradle 2, Gradle 3, and Gradle 4 versions. Such software are called as Software Packages. The version number shown in the title is their base version (or the major version) and the number shown in Version is the minor version. The minor version is the actual software version that’ll be installed on the VM. For example, in Gradle 4, 4 is the major version and 4.1 is the software version.

Gradle software in the Software Catalog

When a new minor version of a software package is available in the Software Catalog, all VM templates using that software package are updated automatically. For example, when Gradle 4.2 is available in the Software Catalog, all VM templates using the Gradle 4 package update automatically to use Gradle 4.2. If there’s an incompatibility between the upgraded software and other installed software of the VM template, an error is reported with suggestions about the cause of the error.

When a new major version of a software is available in the catalog, VM templates using the older versions of the software package aren’t updated automatically. The new major version of the software is added to the catalog as a separate package. For example, when Gradle 5 is available in the Software Catalog, all VM templates using Gradle 2, Gradle 3, or Gradle 4 aren’t updated automatically. You must manually update the VM templates to use the new package.

Add and Manage Build VMs

When you add a Build VM, you allocate a VM on the linked Oracle Cloud Infrastructure Compute Classic service to be used to run builds of jobs.

Each build runs in one build executor, or one VM. You can build up to 99 builds in parallel using the same Build VM template.

Action How To

Add a Build VM

  1. In the navigation bar, click Organization.

  2. Click Virtual Machines.

  3. In the Build VMs tab, click + New VM.

  4. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the Build VM template.

  5. Click Add.

If you have multiple jobs across projects using a common Build VM template, add multiple Build VMs of that template. When builds of those jobs run, DevCS picks a VM that’s available without waiting for a busy VM to get free.

View a Build VM’s log

The Build VM’s log has entries for all events along with information about when the events occurred, the type of event, and event details.

  1. In the navigation bar, click Organization.

  2. Click Virtual Machines.

  3. In the Build VMs tab, select the VM, click Actions the Actions Menu icon, and select Display Log.

  4. In the Provisioning Log window, review the log.

    To download the log file to your computer, click Download Log.

  5. Click Add.

Change a Build VM's template

  1. In the navigation bar, click Organization.

  2. Click Virtual Machines.

  3. In the Build VMs tab, select the VM. From the Template list, and select another template.

Delete a Build VM

When you delete a Build VM, it waits for all builds running on it to complete and won't accept new builds while it’s waiting for the running builds to complete. After all the builds are complete, it shuts down and is removed.

  1. In the navigation bar, click Organization.

  2. Click Virtual Machines.

  3. In the Build VMs tab, select the VM, click Actions the Actions Menu icon, and select Delete.

    To delete multiple VMs, select them, click Update Selected , and select Delete Selected VMs.

If the VM quota is available, the Build VMs of the specified quantity are added to the Build VMs tab. After adding Build VMs, you can configure the jobs to use the VM templates.

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

  1. In the Jobs tab, click + New Job.

  2. In the New Job dialog box, in Job Name, enter a unique name.

  3. To link this job to a merge request, select the Use for Merge Request check box.

  4. Select Create New.

  5. In Software Template, select the Build VM template.

  6. Click Create Job.

Copy an existing job

Sometimes, 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.

After you create the new job, you can change the copied parameters and configuration.

  1. In the Jobs tab, click + New Job.

  2. In the New Job dialog box, in Job Name, enter a unique name.

  3. To link this job to a merge request, select the Use for Merge Request check box.

  4. Select Copy existing job.

  5. From the From Job drop-down list, select the source job.

  6. In Software Template, select the Build VM template.

  7. Click Create Job.

Configure a job

The job configuration page opens immediately after you create a job. You can also open it from the Jobs tab. Click Configure the Gear icon.

Run a build of a job

In the Jobs tab, click Build Now the Build icon.

Delete a job

In the Jobs tab, click Delete Delete.

Configure a Job

You can create, manage, and configure jobs from the Jobs tab of the Build page.

To open a job’s configuration page, in the Jobs tab of the Build page, click the job’s name. In the job’s details page, click Configure. You can also open a job’s configure page from the Build page. In the Jobs tab, for the job you want to configure, click Configure the Gear icon.

Access Project Git Repositories

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

  1. Open the job’s configuration page.

  2. Click Configure the Tools icon, if necessary.

  3. Click the Source Control tab.

  4. From the Add Source Control list, select Git.

  5. In Repository, select the Git repository to track.

    When you created the job, if you selected the Use for Merge Request check box, the field is automatically populated with the ${GIT_REPO_URL} value. Don’t change it.

  6. In Branch, select the branch name of the repository to track. By default, master is set.

    When you created the job, if you selected the Use for Merge Request check box, Branch is automatically populated with the ${GIT_REPO_BRANCH} value. Don’t change it unless you don’t want to link the job with a merge request.

  7. Click Save.

You can specify multiple Git repositories. If you do, set Local Checkout Directory for all Git repositories.

Trigger a Build Automatically on an SCM Update

You can configure a job to monitor its Git repositories and trigger a build automatically after an update is pushed to the Git repository. The builds don’t run automatically for external Git repositories.

  1. Open the job’s configuration page.

  2. Click Configure the Tools icon, if necessary.

  3. Click the Source Control tab.

  4. For the Git repository you want to monitor, select the Automatically perform build on SCM commit check box.

  5. To specify a list of files and directories to track for changes in the repository, expand Advanced Git Settings, and enter the list in Included Region.

    You can use regular expressions to specify files. Each entry must be separated 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

  6. To specify a list of files and directories not to track for changes in the repository, expand Advanced Git Settings, and enter the list in Excluded Region.

    You can use regular expressions to specify files. Each entry must be separated 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’s an overlap between included and excluded regions, exclusions take precedence over inclusion.

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

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.

You specify the schedule using Cron expressions. If you’re not a Cron expert, use the novice mode and set the schedule by specifying values. If you’re a Cron expert, use the Expert mode.

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Triggers tab.

  4. Click Add Trigger and select SCM Polling Trigger.

  5. To use the expert mode, select the Expert mode check box and enter the schedule in the text box.

    The default pattern is 0/30 * * * *, which runs a build every 30 minutes.

    After you edit the expression, it’s validated immediately when the cursor moves out of the text box. Note that other fields of the section aren’t available when the check box is selected.

  6. To use the novice mode, deselect the Expert mode check box and specify the schedule information. The page displays the generated Cron expression next to the Expert mode check box.

  7. To use the novice mode, deselect the Expert mode check box and specify the schedule information in Minute, Hour, Day of the Month, Month, and Day of the Week.

    Click Toggle Recurrence to add or remove 0/or 1/ at the beginning of the value in the Cron expression.

    The page displays the generated Cron expression next to the Expert mode check box.

  8. If necessary, in Comment, enter a comment.

  9. To view and verify the build schedule of the next ten builds, from the timezone drop-down list, select your time zone and then click View Schedule.

  10. Click Save.

To see the SCM poll log of the job, click SCM Poll Log 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

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. Click Configure the Tools icon.
  3. In the Source Control tab, add the Git repository where you want to publish Git artifacts..
  4. Click the Post Build tab.
  5. Click Add Post Build Action and select Git Publisher.
  6. To push Git artifacts to the Git repository only if the build succeeds, select the Publish only if build succeeds check box.
  7. To push merges back to the target remote name, select the Merge results check box.
  8. To push a tag to the remote repository, in Tag to push, 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.

  9. To push a branch to the remote repository, in Branch to push, 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.
  10. 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.

You can perform these configuration actions from the Source Control tab of the job configuration page.

Action How To

Change the remote name of a repository

For the Git repository, expand Advanced Repository Options, and specify the new name in Name. The default remote name is origin.

Specify a reference specification of a repository

A reference repository helps to speed up the builds of the job by creating a cache in the workspace and hence reducing the data transfer. When a build runs, instead of cloning the Git repository from the remote, the build executor clones it from the reference repository.

To create a reference specification of a Git repository, expand Advanced Repository Options, and specify the name in Ref Spec.

Leave the field empty to create a default reference specification.

Specify a local checkout directory

The local checkout directory is a directory in the workspace where the Git repository is checked out when a build runs.

To specify the directory of a Git repository, expand Advanced Repository Options, and specify the path in Local Checkout Directory. If left empty, the Git repository is checked out on the root directory of the workspace.

Checkout the remote repository’s branch and merge it into a local branch

Expand Advanced Git Settings, in Merge another branch, specify the branch name to merge to. If specified, the build executor checks out the revision to build as HEAD on this branch.

If necessary, in Checkout revision, specify the branch to checkout and build as HEAD on the value of Merge another branch.

Configure Git user.name and user.email variables

Expand Advanced Git Settings and in Config user.name and Config user.email, specify the user name and the email address.

Merge to a branch before a build runs

Expand Advanced Git Settings and select the Merge from another repository check box.

In Repository, enter or select the name of the repository to be merged. In Branch, enter or select the name of the branch to be merged. If no branch is specified, the default branch of the repository is used.

The build runs only if the merge is successful.

Prune obsolete local branches before running a build

Expand Advanced Git Settings and select the Prune remote branches before build check box.

Skip the internal tag

When a build runs, the build executor checks out the Git repository to the local repository of the workspace and applies a tag to it. To skip this process, expand Advanced Git Settings and deselect Skip internal tag check box.

Remove untracked files before running a build

Expand Advanced Git Settings and select the Clean after checkout check box.

Retrieve sub-modules recursively

Expand Advanced Git Settings and select the Recursively update submodules check box.

Display commit’s author in the log

By default, the Git change log shows the commit’s commit's Committer . To display commit’s Author, expand Advanced Git Settings and select the Use commit author in changelog check box.

Delete all files of the workspace before a build runs

Expand Advanced Git Settings and select the Wipe out workspace before build check box.

View SCM Changes Log

The SCM 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 SCM Changes page that you open from the job’s details page displays SCM commits from last 20 builds in the reverse order. The SCM 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 schedule 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.

You can specify the schedule using Cron expressions. If you’re not a Cron expert, use the novice mode and set the schedule by specifying values. If you’re a Cron expert, use the Expert mode.

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Triggers tab.

  4. Click Add Trigger and select Periodic Build Trigger.

  5. To use the expert mode, select the Expert mode check box, and enter the schedule in the text box.

    The default pattern is 0/30 * * * *, which runs a build every 30 minutes.

    After you edit the expression, it’s validated immediately when the cursor moves out of the text box. Note that other fields of the section aren’t available when the check box is selected.

  6. To use the novice mode, deselect the Expert mode check box and specify the schedule information. The page displays the generated Cron expression next to the Expert mode check box.

  7. To use the novice mode, deselect the Expert mode check box and specify the schedule information in Minute, Hour, Day of the Month, Month, and Day of the Week.

    Click Toggle Recurrence to add or remove 0/ or 1/ at the beginning of the value in the Cron expression.

    The page displays the generated Cron expression next to the Expert mode check box.

  8. If necessary, in Comment, enter a comment.

  9. To view and verify the build schedule of the next ten builds, from the timezone drop-down list, select your time zone and then click View Schedule.

  10. 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 the job to use the 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 where the user can enter or change the default values of the parameters.

  1. Open the job’s configuration page.

  2. Click Configure the Tools icon.

  3. Click the Build Parameters tab.

  4. From the Add Parameter drop-down list, select the parameter type.

    You can add these types of build parameters:

    Use this parameter type ... To:

    String

    Accept a string value from the user when a build runs. The parameter field appears as a text box in the Configure Parameters dialog box.

    Password

    Accept a password value from the user when a build runs. The parameter field appears as a password box in the Configure Parameters dialog box.

    Boolean

    Accept true or false as input from the user when a build runs. The parameter field appears as a check box in the Configure Parameters dialog box.

  5. Enter values such as name, default value, and description.

  6. Click Save.

While creating the job, if you selected the Use for Merge Request check box, GIT_REPO_URL, GIT_REPO_BRANCH, and MERGE_REQ_ID Merge Request parameters are automatically added to accept the Git repository URL, the Git repository branch name, and the merge request ID as input from the merge request respectively. The GIT_REPO_URL and GIT_REPO_BRANCH variables are automatically set in the Repository and Branch fields of the Source Control tab.

Access an Oracle Cloud Service Using SSH

You can configure a job to use SSH to access any Oracle Cloud service instances that has SSH enabled, such as Oracle Cloud Infrastructure Compute Classic VMs.

You can configure the job to use any of the following options, or both.
  • Create an SSH tunnel to access a process running on a remote system, including an on-premise system, via the SSH port. The SSH tunnel is created at the start of the build job and is destroyed automatically when the job finishes.

  • Set up the default ~/.ssh directory with the provided keys in the build’s workspace for use with the command-line tools. The modifications revert when the job finishes.

To connect to the Oracle Cloud service instance, you need IP address of the server, credentials of a user who can connect to the service instance, and local and remote port numbers.

  1. Open the job’s configuration page.
  2. Click Configure the Tools icon, if necessary.
  3. Click the Build Environment tab.
  4. Click Add Build Environment and select SSH Configuration.
  5. 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.
  6. 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.
  7. In SSH Server Public Key, enter the public key of the SSH server.

    If you’re using a command-line SSH tool, note that the host name and the IP address must match. The host name and the IP address can be comma separated. Example: ssh1.example.com,10.0.0.13 ssh-rss ... .

    Leave the field empty to skip host verification. For command-line tools, such as ssh, add the -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null option explicitly to skip host verification.

  8. To use an SSH tunnel, select the Create SSH Tunnel check box.

    SSH tunnel provides an additional layer of security and can only be set up between trusted hosts. After you select the check box, enter the SSH server details.

    • Username: Name of the user who can connect to the SSH server.

    • Password: Password of the SSH user. Leave the field empty to use the key based authentication.

    • Local Port: Port number of the client used for local port forwarding.

    • Remote Host: Name of the remote host, or an interface on the SSH server.

    • Remote Port: Port number of the remote host or interface.

    • SSH Server: Name or IP address of the target SSH server.

    • Connect String: Displays the connect string to be used to set up the SSH tunnel.

  9. To use command line tools (such as ssh, scp, or sftp), select the Setup files in ~/.ssh for command-line ssh tools check box.
    When a build runs, necessary files with the information that you’ve provided are created for you in the known_hosts file of the ~/.ssh directory in the build system workspace. The files are removed automatically after the build is complete.
  10. Click Save.

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.

Create and Manage Oracle Maven Repository Connections

If your project users access the Oracle Maven Repository frequently, you can create a pre-defined connection for them. Project users can then configure a job and use the connection to access the artifacts of the Oracle Maven Repository while running builds.

To create a connection, you’d need the Oracle Technology Network (OTN) Single Sign-On (SSO) credentials of a user who has accepted the Oracle Maven Repository license agreement.

the project owner icon You must be assigned the project Owner role to add and manage Oracle Maven Repository connections.

Action How To

Add an Oracle Maven Repository connection

  1. In the navigation bar, click Administration.

  2. Click Build.

  3. Expand Maven Connection.

  4. Click Add Maven Connection.

  5. In the Create Maven Connection dialog box, in Connection Name, enter a unique name.

  6. In OTN Username and OTN Password, enter the credentials of a user who has accepted the Oracle Maven Repository license agreement.

  7. In Server Id, if necessary, enter the ID to use for the <server> element of the Maven settings.xml file or use the default maven.oracle.com ID.

  8. Click Create.

Edit a connection

To change the connection’s user credentials or provide another server ID, you can edit the connection.

  1. In the navigation bar, click Administration.

  2. Click Build.

  3. Expand Maven Connection.

  4. Click the connection name and then click the Edit icon.

  5. In the Edit Maven Connection dialog box, if necessary, enter the credentials of a user with valid SSO user name.

    In Server Id, if necessary, enter the ID to use for the <server> element of the Maven settings.xml file. If not provided, the ID defaults to maven.oracle.com.

  6. Click Update.

Delete the connection

  1. In the navigation bar, click Administration.

  2. Click Build.

  3. Expand Maven Connection.

  4. Click the connection name and then click Delete.

  5. In the Delete Maven Connection dialog, click Delete.

Configure a Job to Connect to the Oracle Maven Repository

  1. Open the job’s configuration page.

  2. Click Configure the Tools icon.

  3. Click the Build Environment tab.

  4. Click Add Build Environment and select Oracle Maven Repository Connection.

  5. From Use Existing Connection, select a pre-defined connection. Your project owner has the connection so that you don't have to worry about setting it up.

    If there’s no pre-defined connection available or you want set up your own connection, click the toggle button. In OTN Username and OTN Password, enter the credentials of a user who has accepted the Oracle Maven Repository license agreement.

  6. In Server Id, if required, enter the ID to use for the <server> element of the Maven settings.xml file, or use the default maven.oracle.com ID.

  7. If you’re using a custom settings.xml file, in Custom settings.xml, enter the file’s path.

  8. 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 Configure the Tools icon.

  3. Click the Builders tab.

  4. From Add Builder, select Unix Shell Builder.

  5. In Script, 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.

    You can also use Kubernetes, PSMcli, Docker, Terraform, Packer, and OCIcli commands in the Shell script. Make sure that you have the required software in the job’s Build VM template before you run a build.

  6. To show the values of the variables and hide the input-output redirection in the build log, select the Expand variables in commands, don’t show I/O redirection (-x) option.

    To show the command as-it-is in the build log, select the Show commands exactly as written (-v) option.

  7. Click Save.

Tip:

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

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

  • If both Python 2 and Python 3 are available in the job’s Build VM template, to call Python, use these commands.

    Command Version

    python

    python2

    Python 2

    python3

    Python 3

    pip

    pip of Python 3

    pip3

    pip of Python 3

    To run Python 3, create an isolated environment using virtualenv. To learn more, see https://virtualenv.pypa.io/en/stable/.

  • To clone an external Git repository using a shell command, use the internal URL of the external Git repository. To copy the URL, open the Code page and, from the Repositories drop-down list, select the external Git repository. From the Clone menu, click Copy to clipboard the copy to clipboard icon of the Clone with HTTPS from internal address URL.

    If you’re using an Oracle Linux 6 VM in your job, remove the username from the URL before using it in a shell command. For example, if the copied URL is https://alex.admin%40example.com@developer.us.oraclecloud.com/developer1111-usoracle22222/s/developer1111-usoracle22222_myproject/scm/myextrepo.git, then remove alex.admin%40example.com@ from the URL and use https://developer.us.oraclecloud.com/developer1111-usoracle22222/s/developer1111-usoracle22222_myproject/scm/developer1111-usoracle22222_myproject.git in your shell command.

    the Clone menu of an external Git repository

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. Click Configure the Tools icon.

  4. In the Source Control tab, add the Git repository where you uploaded the build files.

  5. Click the Builders tab.

  6. From Add Builder, select Maven Builder.

  7. In Goals, enter Maven goals, or phases, along with their options. By default, clean and install goals are added.

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

  8. In POM file, enter the Maven POM file name and path, relative to the workspace root. The default value is pom.xml at the Git repository root.

  9. If necessary, specify the advanced Maven options.

    Action How To

    Use a private repository for builds

    Select the Use Private Repository check box.

    You may want to use it to make sure that other Maven build artifacts don’t interfere with the artifacts of this job’s builds. When a build runs, it creates a Maven repository .maven/repo directory in the build executor workspace. Remember selecting this option consumes more storage space of the workspace.

    Use a private temporary directory for builds.

    Select the Use Private Temp Directory check box.

    You may want to use it to create a temporary directory for artifacts or temporary files. When a build runs, it creates a .maven/tmp directory in the workspace. The temporary files may consume large amount of storage, so, remember to clean up the directory regularly.

    Work offline and don’t access remote Maven repositories

    Select the Offline check box.

    Activate Maven profiles

    In Profiles, enter a list of profiles, separated by commas.

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

    Set custom properties

    In Properties, enter custom system properties in the key=value format, specifying each property on its own line. When a build runs, the properties are passed to the build executor in the standard way (example: -Dkey1=value1 -Dkey2=value2)

    Set the Maven verbosity level

    From Verbosity, select the level.

    You may want to use it to set the verbosity of the Maven log output to the build log.

    Set the checksum mode

    From Checksum, select the mode.

    You may want to use it to set the check-sum validation strictness when the build downloads artifacts from the remote Maven repositories.

    Set handling of the SNAPSHOT artifacts

    From Snapshot, select the mode.

    Include other Maven projects to the reactor

    In Projects, enter the comma or space separated list of Maven project jobs to include in the reactor. The reactor is a mechanism in Maven that handles multi-module projects. A project job can be specified by [groupId]:artifactId or by its relative path.

    Resume a Maven project from the reactor

    In Resume From, enter the Maven job project name from where you would like to resume the reactor. The Maven job project can be specified by [groupId]:artifactId or by its relative path.

    Set the failure handling mode

    From Fail Mode, select the mode.

    You may want to use it to set how the Maven build proceeds in case of a failure.

    Set the Make-like reactor mode

    From Make Mode, select the mode. You may want to use it enable Make-like build behavior.

    Configure the reactor threading model

    In Threading, enter the value for experimental support for parallel builds. For example, a value of 3 indicates three threads for the build.

    Pass parameters to Java VM

    In JVM Options, enter the parameters. The build passes the parameters as MAVEN_OPTS.

  10. 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 Configure the Tools icon.

  3. Click the Builders tab.

  4. From Add Builder, select Unix Shell Builder.

  5. In Script, 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
  6. Click Save.

Upload to or Download Dependencies from the Project Maven Repository

To upload or download dependencies while running a build, add the dependency management snippet or the dependency declaration snippet to the POM file.

  1. Copy the distribution management snippet of the project’s Maven repository.
  2. 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:

    Distribution management code snippet in the POM file

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

    Example:

    Job configuration with Maven goals

  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:

    A build’s Maven artifacts

Note:

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

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

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. Click Configure the Tools icon.

  4. In the Source Control tab, add the Git repository where you uploaded the build files.

  5. Click the Builders tab.

  6. From Add Builder, select Ant Builder.

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

  8. In Build File, specify the path of the build file.

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

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

  11. 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/.

Before you can use Gradle, you must create a Build VM template that includes Gradle and then add a Build VM that uses the VM template. If you don’t want to create a template, you can add the software to an existing template. After adding a Build VM, create and configure a job to use the Build VM template and add Gradle commands.

Set Up a Build VM and a Build VM Template with Gradle

the organization administrator icon You must be the Organization Administrator to create a Build VM template and add a Build VM.

  1. On the Organization Administration page, click VM Templates.

  2. In the Build VM Templates tab, click + New Template. Enter name and description, select the platform, and click Create.

    To use an existing template, click its name.

  3. In the Software Catalog, search for Gradle. To see the latest version only, select the Show latest versions only check box.

  4. Select the software tile and click Done.

  5. From the left navigation bar, click Virtual Machines.

  6. In the Build VMs tab, click + New VM.

  7. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the Gradle template.

  8. Click Add.

Configure a Job

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

  2. Open the job’s configuration page.

  3. Click Settings the Gear icon.

  4. In the Software tab, select the Gradle template.

  5. Click Configure the Tools icon.

  6. In the Source Control tab, add the Git repository where you uploaded the build file.

  7. Click the Builders tab.

  8. From Add Builder, select Gradle Builder.

  9. To call the default Gradle script, select Invoke From.

    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.

  10. In Tasks, enter Gradle tasks.

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

  12. In Build file folder, 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.

  13. In Switches, enter Gradle switches.

  14. If you’re 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.

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

Before you can use Node.js, you must create a Build VM template that includes Node.js and then add a Build VM that uses the VM template. If you don’t want to create a template, you can add the software to an existing template. After adding a Build VM, create and configure a job to use the Build VM template and add a Node.js script.

Set Up a Build VM and a Build VM Template with Node.js

the organization administrator icon You must be the Organization Administrator to create a Build VM template and add a Build VM.

  1. On the Organization Administration page, click VM Templates.

  2. In the Build VM Templates tab, click + New Template. Enter name and description, select the platform, and click Create.

    To use an existing template, click its name.

  3. In the Software Catalog, search for Node.js. To see the latest version only, select the Show latest versions only check box.

  4. Select the software tile and click Done.

  5. From the left navigation bar, click Virtual Machines.

  6. In the Build VMs tab, click + New VM.

  7. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the Node.js template.

  8. Click Add.

Configure a Job

  1. If you have a Node.js script, upload it to the project Git repository.

  2. Open the job’s configuration page.

  3. Click Settings the Gear icon.

  4. In the Software tab, select the Node.js template.

  5. Click Configure the Tools icon.

  6. In the Source Control tab, add the Git repository where you uploaded the build file.

  7. Click the Builders tab.

  8. From Add Builder, select Node.js Builder.

  9. To specify the script file, in Source select NodeJS File. In NodeJS File Path, specify the file path in the Git repository.

    To specify the script, in Source select Script. In NodeJS Script, enter the script.

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

Before you can use SQLcl, you must create a Build VM template that includes SQLcland then add a Build VM that uses the VM template. If you don’t want to create a template, you can add the software to an existing template. After adding a Build VM, create and configure a job to use the Build VM template and add a SQLcl commands.

Set Up a Build VM and a Build VM Template with SQLcl

the organization administrator icon You must be the Organization Administrator to create a Build VM template and add a Build VM.

  1. On the Organization Administration page, click VM Templates.

  2. In the Build VM Templates tab, click + New Template. Enter name and description, select the platform, and click Create.

    To use an existing template, click its name.

  3. In the Software Catalog, search for SQLcl. To see the latest version only, select the Show latest versions only check box.

  4. Select the software tile and click Done.

  5. From the left navigation bar, click Virtual Machines.

  6. In the Build VMs tab, click + New VM.

  7. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the SQLcl template.

  8. Click Add.

Configure a Job

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. In the Software tab, select the SQLcl template.

  4. From the Java drop-down list, select version 1.8.x, or later.

  5. Click Configure the Tools icon.

  6. Click the Builders tab.

  7. From Add Builder, select SQLcl Builder.

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

  9. To connect to Oracle Database Exadata Express Cloud Service, in Credentials File, enter the workspace path of the uploaded credentials zip file.

  10. 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.us.oracle.com:1521:adt1100 where adt1100 is the SID, and test_server.us.oracle.com:1521/ora11g where ora11g is the service name.

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

  11. If the SQL statements are available in a file uploaded to the project Git repository, in Source, select SQL File. In SQL File Path, enter the Git repository path of the SQL file. You can copy the file’s path from the Code page.

    To enter SQL statements, in Source, select Inline SQL. In SQL Statements, enter the SQL statements.

  12. In Role, if necessary, select the database role of the user.

  13. In Restriction Level, if necessary, specify the restriction level on the type of SQL statements that are allowed to run.

  14. Click Save.

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

Note:

  • DevCS doesn’t support SQL commands to edit buffer (such as set sqlformat csv) or edit console.

  • You can use build parameters in Username, Password, Connect String, and SQL Statements.

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

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.

Before you can use PSMcli, you must create a Build VM template that includes PSMcli and then add a Build VM that uses the VM template. If you don’t want to create a template, you can add the software to an existing template. After adding a Build VM, create and configure a job to use the Build VM template and add PSMcli commands.

Set Up a Build VM and a Build VM Template with PSMcli

the organization administrator icon You must be the Organization Administrator to create a Build VM template and add a Build VM.

  1. On the Organization Administration page, click VM Templates.

  2. In the Build VM Templates tab, click + New Template. Enter name and description, select the platform, and click Create.

    To use an existing template, click its name.

  3. In the Software Catalog, search for PSMcli. To see the latest version only, select the Show latest versions only check box.

  4. Select the software tile and click Done.

  5. From the left navigation bar, click Virtual Machines.

  6. In the Build VMs tab, click + New VM.

  7. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the PSMcli template.

  8. Click Add.

Configure a Job

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. In the Software tab, select the PSMcli template.

  4. Click Configure the Tools icon.

  5. Click the Builders tab.

  6. From Add Builder, select Invoke PSMcli.

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

  8. In Identity Domain, enter the identity domain.

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

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

  11. Click the Builders tab.

  12. Scroll up and from Add Builder, select Unix Shell Builder.

  13. In Script, enter the PSM commands on separate lines.

  14. Click Save.

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

Access Oracle Cloud Infrastructure Services Using OCIcli

Using Oracle Cloud Infrastructure command line interface (OCIcli) commands, you can create and manage Oracle Cloud Infrastructure objects and services when a build runs.

For more information about OCIcli and its commands, see the Oracle Cloud Infrastructure Command Line Interface documentation.

To configure the job, you need Oracle Cloud Identifier (OCID), an RSA public-private key pair in the PEM format, and the tenancy name. Every Oracle Cloud Infrastructure resource has an Oracle-assigned unique ID called as OCID.

Before you can use OCIcli, you must create a Build VM template that includes OCIcliand then add a Build VM that uses the VM template. If you don’t want to create a template, you can add the software to an existing template. After adding a Build VM, create and configure a job to use the Build VM template and add OCIcli commands.

Set Up a Build VM and a Build VM Template with OCIcli

the organization administrator icon You must be the Organization Administrator to create a Build VM template and add a Build VM.

  1. On the Organization Administration page, click VM Templates.

  2. In the Build VM Templates tab, click + New Template. Enter name and description, select the platform, and click Create.

    To use an existing template, click its name.

  3. In the Software Catalog, search for OCIcli. To see the latest version only, select the Show latest versions only check box.

  4. Select the software tile and click Done.

  5. From the left navigation bar, click Virtual Machines.

  6. In the Build VMs tab, click + New VM.

  7. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the OCIcli template.

  8. Click Add.

Configure a Job

  1. Open the Oracle Cloud Infrastructure Console page.

  2. Click the user’s avatar and select User Details.

  3. In the User Information tab of the User Details page, click Copy to copy OCID to the clipboard.

    OCID in OCI Console
  4. In DevCS , open the job’s configuration page.

  5. Click Settings the Gear icon.

  6. In the Software tab, select the OCIcli template.

  7. Click Configure the Tools icon.

  8. Click the Builders tab.

  9. From Add Builder, select Invoke OCIcli.

  10. In User OCID, paste the OCID you copied.

  11. In Fingerprint, enter the public key fingerprint of the RSA key pair.

  12. In Tenancy, enter the tenancy name.

    You can find the tenancy name from the Oracle Cloud Infrastructure Console page user menu.

    OCI user menu
  13. In Private Key, enter the private key of the RSA key pair.

  14. In Region, select the Oracle Cloud Infrastructure tenancy’s region.

  15. In Identity Domain, enter the identity domain.

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

  17. Scroll up and from Add Builder, select Unix Shell Builder.

  18. In Script, enter the OCIcli commands on separate lines.

  19. Click Save.

You can add multiple Unix Shell Builder steps to run different group of commands. No need to add the Invoke OCIcli build step again. You can also use build parameters in above fields.

Run Docker Commands

You can configure a job to run Docker commands on a Docker container when a build runs.

You should use the Docker container for short tests and builds. Don’t run a Docker container for long tests or builds, else the builds might not finish. For example, if you use a Docker image that’s listening on a certain port and behaves as a web server, the build won’t exit.

For more information about Docker commands, see https://docs.docker.com/.

Tip:

If you face a network issue while running a Docker command, add the HTTP_PROXY and HTTPS_PROXY environment variables in the Docker file.

Before you can use Docker, you must create a Build VM template that includes Dockerand then add a Build VM that uses the VM template. If you don’t want to create a template, you can add the software to an existing template. After adding a Build VM, create and configure a job to use the Build VM template and add Docker commands.

Set Up a Build VM and a Build VM Template with OCIcli

the organization administrator icon You must be the Organization Administrator to create a Build VM template and add a Build VM.

  1. On the Organization Administration page, click VM Templates.

  2. In the Build VM Templates tab, click + New Template. Enter name and description, select the platform, and click Create.

    To use an existing template, click its name.

  3. In the Software Catalog, search for Docker. To see the latest version only, select the Show latest versions only check box.

  4. Select the software tile and click Done.

  5. From the left navigation bar, click Virtual Machines.

  6. In the Build VMs tab, click + New VM.

  7. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the Docker template.

  8. Click Add.

Configure a Job

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. In the Software tab, select the Docker template.

  4. Click Configure the Tools icon.

  5. Click the Builders tab.

  6. From Add Builder, select Docker, and then select the Docker command.

    Use this command ... To ...
    login

    Log in to the Docker registry.

    In Registry Host, select a pre-linked Docker registry, or enter the Docker registry’s host name where the images are stored. Leave it empty to use Docker Hub.

    In Username and Password, enter the credentials of the user who can access the Docker registry.

    build

    Build Docker images from a Dockerfile.

    Specify the registry host name, Docker image name, its version tag, Docker options, and name and the source of the Dockerfile. You can upload the Dockerfile in the Git repository and provide its path, add the Dockerfile code manually, or provide its URL if it’s available on an external source.

    To specify an external source, include the protocol (example, http) in the URL if you’re referencing a remote tar file (example: http://55.555.555.555/me/mydocker.tar.gz). Ignore the protocol if you’re referencing a remote repository (example: git://github.com/me/my.git#mybranch:myfolder).

    To learn more about Docker build command options, see https://docs.docker.com/engine/reference/commandline/build/.

    tag

    Create a target image tag that refers to the source image.

    Specify the registry host name, Docker image name, and its version tag name for the source and target images.

    push

    Push an image to the Docker registry.

    To learn more about push options, see https://docs.docker.com/engine/reference/commandline/push/.

    images

    List available images.

    To learn more about images, see https://docs.docker.com/engine/reference/commandline/images/.

    save

    Save an image to a .tar archive file.

    In Output File, specify the relative path and name of the output .tar file in the workspace.

    load

    Load an image from a .tar archive file.

    In Output File, specify the relative path and name of the output .tar file in the workspace.

    rmi

    Remove an image. You can remove new images, a specific image, or all images.

    To remove a specific image, enter the host name of the registry where the Docker images are stored. Remember that the images are stored in the registry if they are pushed there. Until the images are pushed, the Registry Host is used to form the fully qualified name of the Docker image on the computer where the image is being created.

    version

    View the version of Docker on the build executor.

  7. Click Save.

The Docker logout command runs automatically after all Docker commands have run.

Trigger a Wercker Pipeline

Wercker is a Docker-based platform that provides continuous integration and continuous delivery (CI/CD) capabilities.

To learn more about Wercker, see https://devcenter.wercker.com/.

To trigger the Wercker pipeline from a job’s build, you need your Wercker account’s token.

Get Wercker Authentication Token

  1. In a web browser, open https://app.wercker.com/sessions/new and log in using your Wercker or GitHub account.

  2. In the top-right corner of the page, click the user icon and select Settings.

  3. In the left navigation bar, click Personal Tokens.

  4. In Token Name, enter a name and click Generate.

    This is required if you create a new build.

  5. Copy the generated token value and keep it safe.

    It is important that you save the generated token because you can’t view or copy the token later.

Configure a Job

  1. Open the job’s configuration page.

  2. Click Configure the Tools icon.

  3. Click the Builders tab.

  4. From Add Builder, select Wercker Builder.

  5. In Token, paste the copied Wercker’s authentication token.

  6. Verify the values of Application, Pipeline, and Branch.

    The fields are automatically populated.

  7. In Message, enter a message to be passed to Wercker. When a build runs, the message is displayed in the Runs tab of Wercker.

  8. Click Save.

When a build of the job runs, it triggers the specified Wercker pipeline.

Run Fn Commands

Fn, or Fn Project, is an open-source, container-native, serverless platform for building, deploying, and scaling functions in multi-cloud environments. To run Fn commands when a build runs, you must have access to a Docker container that has a running Fn server.

For more information about Fn, see https://fnproject.io/.

Before you can use Fn, you must create a Build VM template that includes Fnand then add a Build VM that uses the VM template. If you don’t want to create a template, you can add the software to an existing template. After adding a Build VM, create and configure a job to use the Build VM template and add Fn commands.

Set Up a Build VM and a Build VM Template with Fn

the organization administrator icon You must be the Organization Administrator to create a Build VM template and add a Build VM.

  1. On the Organization Administration page, click VM Templates.

  2. In the Build VM Templates tab, click + New Template. Enter name and description, select the platform, and click Create.

    To use an existing template, click its name.

  3. In the Software Catalog, search for Fn. To see the latest version only, select the Show latest versions only check box.

  4. Select the software tile and click Done.

  5. From the left navigation bar, click Virtual Machines.

  6. In the Build VMs tab, click + New VM.

  7. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the Fn template.

  8. Click Add.

Configure a Job

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. In the Software tab, select the Fn template.

  4. Click Configure the Tools icon.

  5. Click the Builders tab.

  6. From Add Builder, select Fn, and then select the Fn command option.

    Use this option ... To ...
    Fn Build

    Build a new function.

    Specify the relative path of the working directory to build the function, Fn build arguments, Docker registry host, and its user name. If you don’t want to use Docker registry’s cache, deselect the Use Docker Cache check box. To display the command’s log in the build’s log, select the Verbose Output check box.

    Fn Push

    Push the image to the Docker registry.

    Specify the relative path of the working directory, Docker registry host, and its user name. To display the command’s log in the build’s log, select the Verbose Output check box.

    Fn Bump

    Bump the version of the func.yaml file.

    Specify the relative path of the working directory and the bump type (Major, Minor, or Patch). To display the command’s log in the build’s log, select the Verbose Output check box.

    Fn Test

    Run Fn tests, if available, against the Fn server.

    Specify the relative path of the working directory. To run tests of all functions, select the Test all functions in the app check box. To display the command’s log in the build’s log, select the Verbose Output check box.

    Fn Deploy

    Deploy functions to the function server. Using the deploy command, you can bump, build, push and update a function.

    In Deploy to App, specify the Fn app name to deploy to. In other fields, specify the working directory, build arguments, Docker registry host, user name, API URL, and the Call URL. Select the desired check boxes, if necessary.

  7. Click Save.

Use SonarQube

SonarQube is an open source quality management software that enables you to continuously analyze your application. When you configure a job to use SonarQube, the build generates an analysis summary that you can view from the job or the build details page.

To learn about SonarQube, see its documentation at https://docs.sonarqube.org.

Set Up SonarQube

To set up a SonarQube system for your project users, you can create a pre-defined SonarQube connection for your users.

To create the connection, you need the URL of a SonarQube Server available on the public internet.

the project owner icon You must be assigned the project Owner role to add and manage SonarQube connections.

Action How To

Add a SonarQube connection

  1. In the navigation bar, click Administration.

  2. Click Build.

  3. Expand SonarQube Server.

  4. Click Add SonarQube Server Connection.

  5. In the Create SonarQube Server dialog box, enter a name for the server, provide the SonarQube server’s URL, and the credentials of a user who has access to the server.

  6. Click Create.

Edit a connection

To change the connection’s user credentials or provide another server ID, you can edit the connection.

  1. In the navigation bar, click Administration.

  2. Click Build.

  3. Expand Maven Connection.

  4. Expand SonarQube Server.

  5. Click the connection name and then click the Edit icon.

  6. In the Edit SonarQube Server dialog box, as necessary, update the SonarQube server’s URL and the credentials of a user who can access the server.

  7. Click Update.

Delete the connection

  1. In the navigation bar, click Administration.

  2. Click Build.

  3. Expand SonarQube Server .

  4. Click the connection name and then click Delete.

  5. In the Delete SonarQube Server dialog, click Delete.

Configure a Job to Connect to SonarQube

You can configure a job to use SonarQube from the Build Environments tab and add a post-build action to publish its reports.

  1. Open the job’s configuration page.
  2. Click the Build Environment tab.
  3. From Add Build Environment, select SonarQube Settings.
  4. From Sonar Server, select the pre-configured SonarQube server.

    The Username, Password, and SonarQube Server URL display the details of the selected user. To add a server, contact the organization administrator.

  5. To provide the SonarQube project name and the SonarQube project key, expand Advanced SonarQube Settings, and update the values. Make sure that the SonarQube project key is unique.

    By default, the project key is set to <organization>_<projectname>.<jobname>and the project name is set to <projectname>.<jobname>.

  6. Click the Post Build tab.
  7. From Add Post Build Action, select SonarQube Result Publisher.
  8. To use the SonarQube Quality Gate status as the build status, select the Apply SonarQube quality gate status as build status check box.
    If the SonarQube Quality Gate status is Passed, the build is marked as successful. If the SonarQube Quality Gate status is Failed, the build is marked as failed. To learn about SonarQube Quality Gates, see https://docs.sonarqube.org/display/SONAR/Quality+Gates.
  9. To create an archive file of the SonarQube analysis files, select the Archive Analysis Files check box.
  10. Click Save.

To view the SonarQube analysis summary, from the job’s details page, click SonarQube Analysis Summary SonarQube Analysis Summary. The SonarQube Analysis Summary displays SonarQube server URL of the job and the analysis summary.

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. From Add Post Build Action, select JUnit Publisher.

  5. In Include JUnit XMLs, specify the path and names of XML files to include. You can also use wildcards.

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

  6. In Exclude JUnit XMLs, specify the path and names of XML report files to exclude. You can also use wildcards.

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

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

  9. To mark the build as failed if the JUnit tests fail, select the Fail the build on fail tests check box.

  10. To archive videos and image files, select the Archive Media Files check box.

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

  1. Open the job’s details page.

  2. Click the Tests icon.

View test results of a particular build

  1. Open the job’s details page.

  2. In the Build History table, click the build number.

  3. Click the Tests icon.

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 Show to download the test image and click Watch 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.

Before you can use Xvfb, you must create a Build VM template with minimum required software and then add a Build VM that uses the VM template. You can use any existing Oracle Linux 7 VM template to run Xvfb, or create a VM template if you don’t want to use an existing VM template. Xvfb isn’t available on an Oracle Linux 6 VM template.

Set Up a Build VM and a Build VM Template with Xvfb

the organization administrator icon You must be the Organization Administrator to create a Build VM template and add a Build VM.

  1. On the Organization Administration page, click VM Templates.

  2. In the Build VM Templates tab, click + New Template. Enter name and description, select Oracle Linux 7 as the platform, and click Create.

  3. Click Done.

  4. From the left navigation bar, click Virtual Machines.

  5. In the Build VMs tab, click + New VM.

  6. In the Add Build VM dialog box, in Quantity, specify the number of VMs you want to allocate. In VM Template, select the Xvfb template.

  7. Click Add.

Configure a Job

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. In the Software tab, select the minimum required software template.

  4. Click the Build Environment tab.

  5. From Add Build Environment, select Xvfb Wrapper.

  6. In Display Number, specify the ordinal number of the display the Xvfb server is running on. The default value is 0. If left empty, a random number is chosen when the build runs.

  7. In Screen offset, specify the offset for display numbers. The default value is 0.

  8. In Screen Size (WxHxD), specify the resolution and color depth of the virtual frame buffer in the WxHxD format. The default value is 1024x758x24.

  9. In Additional options, specify additional Xvfb command line options, if necessary. The default options are -nolisten inet6 +extension RANDR -fp /usr/share/X11/fonts/misc.

  10. In Timeout in seconds, specify the timeout duration for the build to wait before returning control to the job. The default value is 0.

  11. If you don’t want to log the Xvfb output in the build log, deselect the Log Xvfb output check box. The check box is selected by default.

  12. If you don’t want to keep the Xvfb server running for post-build steps, deselect the Shutdown Xvfb with whole job, not just with the main build action check box. The check box is selected by default.

  13. 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. In Javadoc Directory, specify the workspace path where the build executor would publish the generated Javadoc. By default, the path is set to target/site/apidocs .
  4. To configure the build executor to retain Javadoc for each successful build, select the Retain Javadoc for each build check box.
    You may want to do this to browse Javadoc of older builds, but remember that retaining old Javadoc would consume more disk space. By default, the check box isn’t selected.
  5. Click Save.

Archive Artifacts

If you want builds of a job to archive artifacts, you can do so as a post 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 Configure the Tools icon.

  3. Click the Post Build tab.

  4. Click Add Post Build Action and select Artifact Archiver.

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

  6. In Files to exclude, 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.

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

    To archive the Maven POM file along with Maven artifacts, select the Include POM.xml check box.

  8. 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. Click Settings the Gear icon.

  3. Click the General tab, if necessary.

  4. If not selected, select the Discard Old Builds check box.

  5. Configure the discard options.

  6. Click Save.

  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 Configure the Tools icon.

  3. Click the Build Environment tab.

  4. Click Add Build Environment and select Copy Artifacts.

  5. In From Job, select the job whose artifacts you want to copy.

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

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

    If you specify no value, the build copies all artifacts. The archive.zip file is never copied.

  8. In Target Directory, specify the workspace directory where the artifacts will be copied.

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

  10. By default, if a build can’t copy artifacts, it’s 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.

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

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the General tab.

  4. In Name and Description, update the job name and description.

  5. Click Save.

Check the software available on the job’s Build VM template

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Software tab.

  4. See the software and their versions. You can change versions of some software, such as Java SE. Select the version from the drop-down list.

  5. 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:

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the General tab.

  4. Select the Execute concurrent builds if necessary check box.

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

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Advanced tab.

  4. Select the Quiet period check box.

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

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Advanced tab.

  4. Select the Retry Count check box.

  5. In Build Retries specify the number of times the build executor tries the build.

    In SCM Retries specify the number of times the build executor tries the build to checkout files from the Git repository.

  6. Click Save.

Abort a build if it’s stuck for some duration

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Advanced tab.

  4. Select the Abort the build if it is stuck check box.

  5. In Hours and 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 on abort check box to mark the build as failed, rather than aborted.

  6. Click Save.

Remove timestamps from the build log

By default, build logs are timestamped, however you can configure a job to remove them from the log.

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Advanced tab.

  4. Deselect the Add Timestamps to the Console Output check box.

  5. Click Save.

Set the maximum size of the console log

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Advanced tab.

  4. In Max Log Size (MB), set the size. The default value is 50 MB and the maximum value is 1000 MB.

  5. Click Save.

Change a Job’s Build VM Template

You can change a job’s Build VM template after you create the job.

Contact the Organization Administrator to create a Build VM template or install software to a template.

  1. Open the job’s configuration page.

  2. Click Settings the Gear icon.

  3. Click the Software tab.

  4. In Software Template, select the Build VM template that you want to use for your builds.

  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 Build Now.

Run a build on an SCM update

See Trigger a Build Automatically on an SCM Update.

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 Console

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

Javadoc Javadoc

View Javadoc of the build.

The report is available only if the application’s build generated a Javadoc.

SCM Poll Log 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 Latest SCM Poll Log to view the Git SCM polling log of the last build.

Test Results 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 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.

SonarQube Analysis Summary SonarQube Analysis Summary

View the SonarQube analysis report of the job.

Viewing a Project’s Build History

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

To view the build history, in the Build Queue box of the Build page, click the View Recent Build History link. The history page shows the log of all jobs and their builds. Click a job name link to open its job details page. Click a build number link to open its build details page. Click Console 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 who or how the build was triggered, its status, build number, date-time stamp, a Console Console icon to open the build’s console, and a Delete Delete icon to delete the build.

Note:

  • In the By column, the icons indicate the following:

    • User User: Indicates the build was initiated by a user.

    • SCM Change SCM Change: Indicates the build was initiated by an SCM change.

    • Pipeline Pipeline: Indicates the build was initiated by a pipeline. Click to open the build’s pipeline instance.

    • Periodic Build Trigger Periodic Build Trigger: Indicates the build was triggered by a periodic build trigger.

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

    To download artifacts of a particular build, in the Build History, click the build number, and then click 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

  1. Open the job’s details page.

  2. Click the On toggle button, if necessary.

  3. Click CC Me.

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

  5. Click OK.

Disable email notifications of the job to all subscribed members

  1. Open the job’s details page.

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

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.

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.

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

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

NODE_HOME

The path of the Node.js home directory.

NODE_PATH

The path of the Node.js modules directory.

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 are available in the Software Catalog of Build VM templates.

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 Unix Shell builder. You should use the PATH variable and other environment variables to access the installed software.

This table lists software installed on the build executor in addition to the software installed on the operating system.

Software Version

Ant

1.9.6

Docker

1.12.6 (Oracle Linux 6)

17.12 (Oracle Linux 7)

Findbugs

3.0.1

Firefox

45.x (Oracle Linux 6)

52.x (Oracle Linux 7)

Fn

0.5.x (Oracle Linux 7)

Git

1.7.1

Gradle

4.x

3.x

2.x

Java

10.x

9.x

1.8.x

1.7.x

1.6.x

Kubectl

1.8.4

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

OCIcli

2.4.32

Oracle ATG 11

11.1.0.1

Oracle Developer Studio 12c 12.5

12.5

Oracle Forms Developer 12

12.2.1.3.0

Oracle Instant Client 12c

12.1.0.2.0

Oracle JDeveloper Studio 12

12.2.1.3.0

Oracle JDeveloper Studio 11

11.1.1.7.1

Oracle SOA Suite 12

12.2.1.3.0

12.2.1.2.0

12.2.1.1.0

12.1.3.0.0

Packer

1.2.4

PSMcli

1.1.19

Python

3.6.x

3.5.x

2.6.x (Oracle Linux 6)

2.7.x (Oracle Linux 7)

Python – pip3

9.0.x

Ruby

1.9.3p488

SQLcl

17.x

4.x

SFTP

yum:latest

Terraform

0.11.8

Xvfb

1.15.0 (Oracle Linux 7)

To know about the environment variables that you can use to access the software, see 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.

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:

Import External Hudson Jobs

If you are using an on-premise Hudson build system and want to move to the Oracle Developer Cloud Service (DevCS) build system, you can import your Hudson jobs to the DevCS build system.

the project owner icon You must be assigned the project Owner role to import jobs.

From your external Hudson installation, create a zip file of the jobs and then import the jobs to your DevCS project. Before you import your jobs, upgrade your current Hudson installation to version 3.2.2 to resolve any warning messages during the import.

  1. On your Hudson installation computer, open the command-line and navigate to the HUDSON_HOME/jobs directory.

  2. Run the jar -cvfM <jobname>.zip */config.xml command to create a <jobname>.zip file.

    For example, the jar -cvfM jobs.zip */config.xml command creates a jobs.zip file.

    If the zip file contains community Hudson jobs, the parent directory name of the config.xml file becomes the job name when the zip file is uploaded to DevCS.

  3. Before you upload the zip file, confirm the following:

    • The job file name doesn’t contain the period (.) character. Usually, old Hudson jobs contain a period in the file name if the teams feature is enabled. If the period character exists, rename the job to remove the period character.

    • If your current Hudson installation is on a Windows computer, replace \ in the file paths with /.

  4. In DevCS, open your project.

  5. In the navigation bar, click Administration.

  6. Click Job Import.

  7. In the Job Import page, drag-and-drop the zip file to the Drag a zip file here drop area. You may also click select a zip file, browse, select the zip file, and click Open.

  8. Click Upload File to upload the zip file.

    While uploading the zip file, it goes through various validation processes, such as:

    • File format error or empty zip file error

      If there’s a zip file error, create another zip file of the jobs and upload it again.

    • Duplicate job names

      While uploading the zip file, name of each job is checked against the names of the existing jobs of the Builds page and with the other jobs' names in the zip file being uploaded. If a job name is found to be already in use, it’s renamed to add a number suffix (for example, my-job, my-job1, my-job2). If required, you may rename the job in the Job Configuration page.

    • Incompatible Hudson plugins

      By default, jobs with incompatible plugins aren’t uploaded. While uploading, the incompatible jobs generate warnings that you should review after the upload is complete.

    • Unknown job

      While uploading, job dependencies are checked against the existing jobs and the jobs found in the zip file. Missing dependencies report an error and aren’t imported. If required, click Cancel to cancel the job.

  9. Select the check boxes of the jobs to import and click Import Jobs.

    If a job of the same name exists, you are prompted to provide a new name to the imported job. If the Status of a job shows an error, fix the error in the zip file and then try again.

    After the import is successful, the result page shows a message indicating the number of imported jobs along with their names. Click Start Another Import to import another zip file.

  10. Open the Builds page and configure the imported jobs, as required.