Configure and Run Project Jobs and Builds
Oracle Developer Cloud Service (DevCS) includes continuous integration services to build project source files. You can configure the builds from the Builds page.
The Builds page, also called the Jobs Overview page, displays information about all build jobs of the project and provides links to configure and manage them.
What is a Job and a Build?
A Job is a configuration that defines the builds of your application. A Build is a result of a job’s run.
A job defines where to find the source code files, how and when to run builds, the software and the environment required to run builds. When a build runs, it creates packaged archives of the application that you can deploy to a web server. A job can have hundreds of builds. Each build would’ve its artifacts, logs, and reports.
Build Concepts and Terms
Here are some terms that this documentation uses to describe the build features and components.
Term | Description |
---|---|
Build System | Software that automates the process of compiling, linking and packaging the source code into an executable form. |
Build executor | A basic block that enables a build to run. Each build uses one build executor. |
Workspace | A temporary directory used by the build executor to download source code files and generate artifacts when a build runs. |
Build artifact | A file generated by a build. It could be a packaged archive file, such as a .zip or .ear file, that you can deploy to a build server. |
Trigger | A condition to run a build. |
Create and Manage Jobs
To run builds and generate artifacts that you can deploy, you must create a job. You can create a job from the Build page.
Action | How To |
---|---|
Create a blank job |
|
Copy an existing job |
At times, you may want to copy parameters and configuration of a job to another. You can do that when you create a job. You can’t copy the configuration of an existing job to another existing job.
After you create the new job, you can change the copied parameters and configuration. Note that the job is disabled by default to prevent it from running any scheduled build while you are configuring the job. To run builds of the copied job, you must enable it manually. |
Configure a job |
The job configuration page opens immediately after you create a job. You can also open it from the Jobs tab. From the jobs list, click the job name, and then click Configure. |
Run a build of a job |
From the jobs list, click Build Now . |
Delete a job |
From the jobs list, click the job name, and then click Delete. |
Configure a Job
You can create, manage, and configure jobs from the of the Builds page.
To open a job’s configuration page, in the Builds page, click the job’s name. In the job’s details page, click Configure.
Access Project Git Repositories
You can configure a job to access project’s Git repositories and their source code files.
- Open the Configure Build Job page of the job.
- Click the Source Control tab.
- Select the Git option.
- In Repository, select the Git repository.
- To specify a branch other than the default branch, in Branches, click Add and select the branch in Branch Specifier.
Specify ** to examine all branches for changes. The branch with the most recent changes will be used.
Click Advanced to set the advanced settings for the branch.
- Click Save.
Trigger a Build Automatically on SCM Commit
You can configure a job to monitor its Git repositories and trigger a build automatically after a commit is pushed to the Git repository.
-
Open the job’s configuration page.
-
Click the Triggers tab.
-
Select the Based on SCM polling schedule check box.
-
To specify a list of files and directories to track for changes in the repository, in the Source Control tab, expand Advanced Git Settings, and enter the list in Included Region. You can use a regular expressions to specify files.
You must separate each entry by a new line. An empty list implies that all files and directories must be tracked.
For example, this list configures the job to trigger a build when a user adds or updates an
.html
,.jpeg
, or.gif
file in themyapp/src/main/web/
directory of the specified Git repository.myapp/src/main/web/.*\.html
myapp/src/main/web/.*\.jpeg
myapp/src/main/web/.*\.gif
-
To specify a list of files and directories not to track for changes in the repository, in the Source Controltab, expand Advanced Git Settings, and enter the list in Excluded Region. You can use a regular expressions to specify files.
You must separate each entry by a new line. An empty list implies that all files and directories must be tracked. If a change occurs in any of the specified files or directories, a build won’t run. If there is an overlap between included and excluded regions, exclusions take precedence over inclusion.
-
To exclude users whose commits to the repository don’t trigger builds, in Excluded User, enter the list of user names.
-
Click Save.
Trigger a Build Automatically on SCM Polling
SCM polling enables you to configure a job to periodically check the job’s Git repositories for any commits pushed since the job’s last build. If updates are found, it triggers a build. You can configure the job and specify the schedule in Coordinated Universal Time (UTC). UTC is the primary time standard by which the world regulates clocks and time.
-
Open the job’s configuration page.
-
Click the Triggers tab.
-
Select the Based on SCM polling schedule check box.
-
In Schedule, specify the schedule using Cron expressions.
-
To not to run a build on every push to the project Git repository, select the Do not poll on SCM change check box. The builds now run only on the specified schedule.
-
Click Save.
To see the SCM poll log of the job after the build runs, in the job's details page or the build's details page, click SCM Poll Log .
Generate Cron Expressions
You can use Cron expressions to define periodic build patterns.
For more information about Cron, see http://en.wikipedia.org/wiki/Cron
.
You can specify the Cron schedule information in the following format:
MINUTE HOUR DOM MONTH DOW
where:
-
MINUTE
is minutes within the hour (0-59) -
HOUR
is the hour of the day (0-23) -
DOM
is the day of the month (1-31) -
MONTH
is the month (1-12) -
DOW
is the day of the week (1-7)
To specify multiple values, you can use the following operators:
-
*
to specify all valid values -
-
to specify a range, such as1-5
-
/
or*/X
to specify skips of X's value through the range, such as0/15
in theMINUTE
field for0,15,30,45
-
A,B,...,Z
can be used to specify multiple values, such as0,30
or1,3,5
Access Files of a Git Repository's Private Branch
To access a Git repository's private branch, configure the job to use SSH.
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.
Advanced Git Options
When you configure the Git repositories of a job, you can also configure the job with some advanced Git options, such as change the remote name of the repository, set the checkout directory in the workspace, and whether to clean the workspace before a build runs.
Use these fields of the Source Control tab of the job's configuration to set advanced settings.
Advanced Repository SettingsElement | Description |
---|---|
Name |
Enter the name of the repository. Leave the field empty to use the default name of the repository. |
Reference spec |
Specify the reference specification of the repository. This is an optional field. Leave the field empty to create a default reference specification. |
Local Subdirectory |
Specify a local directory where the Git repository will be checked out. If left empty, the workspace root itself will be used. |
Element | Description |
---|---|
Included Regions |
Enter the list of files and directories that will be tracked for changes in the SCM. If a change occurs in any of the specified files or directories, a build is triggered automatically. Each inclusion uses regular expression pattern matching, and must be separated by a new line. An empty list implies that all files and directories will be tracked. For example, the following list illustrates that a build will be triggered when any HTML, JPEG, or GIF file is committed to the
|
Excluded Regions |
Enter the list of files and directories that will not be tracked for changes in the SCM. If a change occurs in any of the specified files or directories, a build will not run. If there is an overlap between included and excluded regions, exclusions take precedence over inclusion. |
Excluded Users |
Enter the list of users whose commits to the SCM will not trigger builds. You can use literal pattern matching and users must be separated by a new line. |
Checkout/merge to local branch |
Specify the branch name to merge to. If specified, checkout the revision to build as |
Config user.name Value |
Enter a user name value for the Git |
Config user.email Value |
Enter the user’s email address for the Git |
Merge options |
Select the Merge before build check box to perform a merge to a particular branch before running a build. Enter the name of the repository that will be merged in Name of repository and the branch name in Branch to merge to. The build will run if the merge is successful. |
Prune remote branches before build |
Select the check box to run the |
Skip internal tag |
Select the check box to skip the internal tag. By default, a tag is applied to the local repository after the code is checked out. |
Clean after checkout |
Select the check box to run the |
Recursively update submodules |
Select the check box to retrieve all sub-modules recursively. |
Use commit author in changelog |
Select the check box to use the commit's Git creates a changeset every time you do a checkin. All the files that are checked in together are included in the changeset. |
Wipe out workspace before build |
Select the check box to delete the contents of the workspace before running a build. |
View Changes Log
The Change log displays the files that were added, edited, or removed from the job’s Git repositories before the build was triggered.
You can view the SCM changes log from the job’s details page and a build’s details page. The Recent Changes page that you open from the job’s details page displays SCM commits from last 20 builds in the reverse order. The Changes page that you open from a build’s details page displays SCM commits that happened after the previous build.
The log shows build ID, commit messages, commit IDs, and affected files.
Trigger a Build Automatically on a Schedule
You can configure a job to run builds on a specified schedule specified in Coordinated Universal Time (UTC). UTC is the primary time standard by which the world regulates clocks and time.
-
Open the job’s configuration page.
-
Click the Triggers tab.
-
Select the Based on this schedule check box.
-
In Schedule, specify the schedule using Cron expressions.
-
Click Save.
Use Build Parameters
Using build parameters, you can pass additional information when a build runs that is not available at the time of job configuration.
You can configure a job to use a parameter and its value as an environment variable or through variable substitution in other parts of the job configuration. When a build runs, a Configure Parameters dialog box opens so you can enter or change the default values of the parameters.
- Open the Configure Build Job page of the job.
- Click the Build Parameters tab.
- Select the This build is parameterized check box.
- From the Add Parameter drop-down list, select the parameter type.
- Enter values such as name, default value, and description.
- Click Save.
When the Enable merge requests parameters check box is selected, the job configuration creates three String parameters GIT_REPO_URL, GIT_REPO_BRANCH, and MERGE_REQ_ID to accept the Git repository URL, the Git repository branch name, and the merge request ID as input from the merge request respectively.
Access the Oracle Maven Repository
The Oracle Maven Repository contains artifacts, such as ADF libraries, provided by Oracle. You may require these artifacts to compile, test, package, perform integration testing, or deploy your applications. For more information about the Oracle Maven repository, see https://maven.oracle.com/doc.html
.
To build your applications and access the Oracle Maven Repository, you configure the job and provide your credentials to access the repository.
-
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. -
Configure the POM file and add the Oracle Maven Repository details.
-
Add a
<repository>
element to refer tohttps://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 tohttps://maven.oracle.com
.Example:
<pluginRepositories> <pluginRepository> <name>OracleMaven</name> <id>maven.oracle.com</id> <url>https://maven.oracle.com</url> </pluginRepository> </pluginRepositories>
-
Commit the POM file to the project Git repository.
-
-
If you’re a project owner, set up Oracle Maven Repository connections for the project’s team members.
-
Create and configure a job to access Oracle Maven Repository.
Configure a Job to Connect to the Oracle Maven Repository
- Open the Environment tab.
- Select the Connect Oracle Maven Repository check box.
The following table highlights what options you can set for the Oracle Maven Repository.
Element Description OTN Login
Enter your OTN SSO user name.
OTN Password
Enter your OTN SSO password.
Server Id
If required, enter the ID to use for the
<server>
element of the Mavensettings.xml
file. If not provided, the ID will default tomaven.oracle.com
.Custom settings.xml
If you are using a custom
settings.xml
file, enter the path to the file in the build workspace. - Click Save.
Run UNIX Shell Commands
You can configure a job to run a shell script or commands when a build runs.
-
Open the job’s configuration page.
-
Click the Build Steps tab.
-
From Add Build Step, select Execute Shell.
-
In Command, enter the shell script or commands.
The script runs with the workspace as the current directory. If there is no header line, such as
#!/bin/sh
specified in the shell script, then the system shell is used. You can also use the header line to write a script in another language, such as Perl (#!/bin/perl
) or control the options that shell uses.By default, when a build runs, it invokes the shell with the
-ex
option. It prints all commands before they run. The build failsif any of the commands exits with a non-zero exit code. You can change this behavior by adding the#!/bin/...
line.Tip:
Don’t enter a long shell script. For a long script, create a script file and add it in the Git repository. You can run the script with a command (such asbash -ex /myfolder/myscript.sh
). -
Click Save.
Build Maven Applications
Using Apache Maven, you can automate your build process and download dependencies, as defined in the POM file.
- Upload the Maven POM files to the project Git repository.
- Open the job’s configuration page.
- In the Source Controltab, add the Git repository where you uploaded the build files.
- Click the Build Steps tab.
- From Add Build Step, select Invoke Maven 2 or Invoke Maven 3.
The following table lists the fields of the Maven section.
Element Description Goals
Enter Maven goals, or phases, to run. This is a required field.
For example:
clean
andinstall
are added by default.For more information about Maven goals, see the Maven Lifecycle Reference documentation at
http://maven.apache.org
.Properties
Enter custom system properties in the
key=value
format. This is an optional field.POM File
Enter the Maven POM file name and location, relative to the workspace root. This is an optional field.
Private repository
Select the check box to use a private repository for builds. This is an optional field.
Private temporary directory
Select the check box to use a private temporary directory for builds. This is an optional field.
Offline
Select the check box to work offline. This is an optional field.
Profiles
Enter the list of profiles to activate. The list can be comma or space separated. This is an optional field.
For more information about Maven profiles, see the Maven documentation at
http://maven.apache.org
.Show Errors
Select the check box to produce execution error detail messages. This is an optional field.
Verbosity
Select the Maven verbosity level from the list. You can select the level as
NORMAL
,QUIET
, orDEBUG
. This is an optional field.Checksum Mode
Select the checksum handling mode from the list. You can select the mode as
NORMAL
,STRICT
, orLAX
. This is an optional field.Snapshot Updates
Select how
SNAPSHOT
artifact updates are handled. You can select the handling mode asNORMAL
,FORCE
, orSUPPRESS
. This is an optional field.Recursive
Indicates that all sub-modules will build recursively. The check box is selected by default. This is an optional field.
Projects
Enter the list of projects to include in the reactor. The reactor is a mechanism in Maven that handles multi-module projects. This is an optional field.
A project can be specified by
[groupId]:artifactId
or by its relative path. The list can be comma or space separated.Resume From
Enter the project name from where you would like to resume the reactor. The project can be specified by
[groupId]:artifactId
or by its relative path. This is an optional field.Fail Mode
Select the failure handling mode from the list. You can select the handling mode as
NORMAL
,AT_END
,FAST
, orNEVER
. This is an optional field.Make Mode
Select the Make-like reactor mode from the list. You can select the mode as
NONE
,DEPENDENCIES
,DEPENDENTS
, orBOTH
. This is an optional field.Threading
Enter the configuration of the reactor threading model. This is an optional field.
JVM Options
Enter the parameters to be passed to the Java VM when running Maven via the
MAVEN_OPTS
environment variable. This is an optional field. - 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.
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.
-
Open the job’s configuration page.
-
Click the Build Steps tab.
-
From Add Build Step, select Execute Shell.
-
In Command, enter this command.
mvn install:install-file -Dfile=$WLS_HOME/server/lib/weblogic-maven-plugin.jar -DpomFile=$WLS_HOME/server/lib/pom.xml mvn com.oracle.weblogic:weblogic-maven-plugin:deploy
-
Click Save.
Upload to or Download Artifacts from the Project Maven Repository
To upload artifacts to the Maven repository, you'll use the distributionManagement
snippet in the POM file. To download artifacts from the Maven repository, use the repositories
snippet in the POM file.
Note that the credentials in settings.xml
aren’t required to access the project’s Maven repository when running a build. The Build job has full access to the project’s Maven repository for uploads and downloads.
Build Ant Applications
Using Apache Ant, you can automate your build processes as described in its build files. For more information, see https://ant.apache.org/
.
-
Upload the Ant build files (such as
build.xml
andbuild.properties
) to the project Git repository. -
Open the job’s configuration page.
-
In the Source Controltab, add the Git repository where you uploaded the build files.
-
Click the Build Steps tab.
-
From Add Build Step, select Invoke Ant .
-
In Targets, specify the Ant targets or leave it empty to run the default Ant target specified in the build file.
-
InBuild File, specify the path of the build file.
-
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, usevarname=
in the script. -
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. -
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/
.
https://docs.gradle.org/current/userguide/gradle_wrapper.html
.
Configure a Job to Run Gradle Commands
-
Upload the
build.gradle
file to the project Git repository. -
Open the job’s configuration page.
-
Click the Build Steps tab.
-
From Add Build Step, select Invoke Gradle.
-
To invoke the default Gradle script, select Invoke Gradle. From Gradle Version, select the Gradle version.
To use Gradle wrapper script, select Use Gradle Wrapper. If you want to use the
gradlew
command as an executable command, select the Make gradlew executable check box. To use thegradlew
command from the root build script directory, select the From Root Build Script Dir check box. -
In Build step description, enter a description.
-
In Switches, enter Gradle switches.
-
In Tasks, enter Gradle tasks.
-
In Root Build Script, enter the path and directory name of the top-level
build.gradle
file if it’s available in a directory other than the module root directory. The path must be relative to the root directory.If left empty, the path defaults to
build.gradle
in the root directory. -
In Build File, enter the name and path of the Gradle
build.gradle
file. -
If you are using a multi-executor slave, select the Force GRADLE_USER_HOME to use workspace check box to set the
GRADLE_USER_HOME
to the workspace and avoid collisions while accessing Gradle cache.By default,
GRADLE_USER_HOME
is set to$HOME/.gradle
. -
Click Save.
Build Node.js Applications
Using Node.js, you can develop applications that run JavaScript on a server. For more information, see https://nodejs.org
.
Configure a Job to Build a Node.js Application
-
Open the job’s configuration page.
-
In the Source Control tab, add the Git repository where you uploaded the script file.
-
Click the Environment tab.
-
Select the Use NodeJS Version check box.
-
From NodeJS Installation, select the Node.js version.
-
Click the Build Steps tab.
-
From Add Build Step, select Invoke NodeJS.
-
In Script, enter the script.
-
Click Save.
Access an Oracle Database Using SQLcl
Using SQLcl, you can run SQL statements from a build to connect and access an Oracle Database. You can use SQLcl to access any Oracle Database available on public internet that you can connect to using a JDBC connect string. You can run DML, DDL, and SQL Plus statements. You can also use SQLcl in a test scenario and run SQL scripts to initialize seed data or validate database changes.
SQLcl requires Java SE 1.8 or later. To learn more about SQLcl, see http://www.oracle.com/technetwork/developer-tools/sqlcl/overview/index.html
. Also see Using the help command in SQLcl in Using Oracle Database Exadata Express Cloud
Service and the SQL Developer Command-Line Quick Reference documentation to know more about using SQLcl supported commands.
To connect to Oracle Database Exadata Express Cloud Service, download the ZIP file that contains its credentials and upload it to the job’s Git repository. You can download the ZIP file from the Oracle Database Cloud Service service console. See Downloading Client Credentials in Using Oracle Database Exadata Express Cloud Service.
Configure a Job to Run SQLcl Commands
- DevCS doesn’t support SQL commands to edit buffer (such as
set sqlformat csv
) or edit console. - DevCS doesn’t support build parameters in the SQL file.
- If you are using Oracle REST Data Services (ORDS), some SQLcl commands, such as the BRIDGE command, requires a JDBC URL.
Example:
BRIDGE table1 as "jdbc:oracle:thin:DEMO/demo@http://examplehost.com/ords/demo"(select * from DUAL);
- To mark a build as failed if the SQL commands fail, add the
WHENEVER SQLERROR EXIT 1
line to your script.
-
Open the job’s configuration page.
-
Click the Main tab.
-
From the JDK drop-down list, select JDK 8, or later.
-
Click the Build Steps tab.
-
From Add Build Step, select SQLcl Builder.
-
In Username and Password, enter the user name and password of the Oracle Database account.
-
In Credentials File, enter the workspace path of the uploaded credentials zip file.
-
In Connect String, enter the JDBC or HTTP connection string of the Oracle Database account using any of the
host_name:port:SID
orhost_name:port/service_name
formats.JDBC Example:
test_server.oracle.com:1521:adt1100
whereadt1100
is the SID, andtest_server.oracle.com:1521/ora11g
whereora11g
is the service name.HTTP Example:
http://test_server.oracle.com:8085/ords/demo
-
In Source, select SQL File if the SQL statements are in a file uploaded to the project Git repository. Select Inline SQL to specify the SQL statements.
-
If you selected SQL File in Source, then in SQL File Path, enter the path of the SQL file in the Git repository. You can copy the file’s path from the Code page.
-
If you selected Inline SQL in Source, then in SQL Statements, enter the SQL statements in the code editor.
-
In Role, elect the database role of the user. By default, it is set to
Default
. -
In Restriction Level, Specify the restriction level on the type of SQL statements that are allowed to run. By default, it is set to
0
. -
Click Save.
When a build runs, DevCS stores your Oracle Database credentials in the Oracle Wallet. Check the build’s log for the SQL output or errors.
Run Oracle PaaS Service Manager Commands Using PSMcli
Using Oracle PaaS Service Manager command line interface (PSMcli) commands, you can create and manage the lifecycle of various services in Oracle Public Cloud. You can create service instances, start or stop instances, or remove instances when a build runs.
For more information about PSMcli and its commands, see About the PaaS Service Manager Command Line Interface in PaaS Service Manager Command Line Interface Reference.
Configure a Job to Run PSMcli Commands
-
Open the job’s configuration page.
-
Click the Build Steps tab.
-
From Add Build Step, select Invoke PSMcli.
-
In Username and Password, enter the user name and password of the Oracle Cloud account.
-
In Identity Domain, enter the identity domain.
-
In Region, select your identity domain’s region.
-
In Output Format, select the preferred output format: JSON (default) or HTML.
-
From Add Build Step, select Execute Shell.
-
In Command, enter the PSM commands on separate lines.
-
Click Save.
You can add multiple shell steps to run different group of commands. Don’t add the PSMcli build step again.
Publish JUnit Results
If you use JUnit in your application to run test scripts, you can configure your job to publish JUnit test reports and get useful information about test results, such as historical test result trends, failure tracking, and so on.
-
Upload your application with test script files to the Git repository.
-
Open the job’s configuration page.
-
Click the Post Build tab.
-
Select the Publish JUnit test result report check box.
-
In Test Report XMLs, specify the path and names of XML files to include.
If you are using Ant, specify the path such as
**/build/test-reports/*.xml
. If you are using Maven, specify the path such astarget/surefire-reports/*.xml
. Make sure that you don’t include any non-report files into this pattern. -
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.
-
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.
-
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 |
|
View test results of a particular build |
|
View test suite details |
On the Test Results page, click the All Tests toggle button. From the Suite Name, click the suite name. |
View details of a test |
Open the test suite details page and click the test name. To view details of a failed test, on the Test Results page, click the All Failed Tests toggle button, and then click the test name. |
View test results history |
On the Test Results page, click View Test Results History. |
If you configure the job to archive videos and image files, click Show to download the test image and click Watch to download the test video file.
The supported image formats are .png
, .jpg
, .gif
, .tif
, .tiff
, .bmp
, .ai
, .psd
, .svg
, .img
, .jpeg
, .ico
, .eps
, and .ps
.
The supported video formats are .mp4
, .mov
, .avi
, .webm
, .flv
, .mpg
, .gif
, .wmv
, .rm
, .asf
, .swf
, .avchd
, and .m4v
.
Use the Xvfb Wrapper
Xvfb is an X server that implements the X11 display server protocol and can run on machines with no physical input devices or display.
Configure a Job to Run Xvfb
-
Open the Build Environment tab.
-
Click Add Build Environment and select Xvfb Wrapper.
The following table highlights what options you can set for the Xvfb Wrapper.
Element Description Display Number
Specify the ordinal number of the display the Xvfb server will be running on. The default value is 0. If left empty, a random number will be chosen.
Screen offset
Specify the offset for display numbers. The default value is 0.
Screen Size (WxHxD)
Specify the resolution and color depth of the created virtual frame buffer in the WxHxD format. The default value is 1024x758x24.
Additional options
Specify any additional Xvfb command line options. The default options are
-nolisten inet6 +extension RANDR -fp /usr/share/X11/fonts/misc
.Timeout in seconds
Specify the timeout duration for the build to wait before returning control to the job. The default value is 0.
Log Xvfb output
The check box is selected by default to redirect the output of Xvfb to the job log. Deselect the check box if you do not want to redirect the output.
Shutdown Xvfb with whole job, not just with the main build action
The check box is selected by default to keep the Xvfb server running for post-build steps. Deselect the check box if you do not want to keep the server running.
-
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.
-
Open the job’s configuration page.
-
Click the Post Build tab.
-
Select the Archive the Artifacts check box.
-
In Files to archive, enter space or comma separated list of files (with path) to archive. You can use wildcards too. Example:
module/dist/**/*.zip
.To enable automatic validation for file masks, select the Enable auto validation for file masks check box.
-
In Excludes, enter space or comma separated list of files (with path) to exclude.
A file that matches the exclude pattern isn’t archived even if it matches the pattern specified in Files to archive.
-
To discard artifacts from older builds and save artifacts from the last stable build, select the Discard all but the last successful/stable artifact to save disk space check box. Artifacts from the last unstable build or last failed build are also saved if they are newer than the last stable build.
-
From Compression Type, select the archive format.
-
If your application is a Maven application and you want to archive Maven artifacts, select the Archive Maven 3 Artifacts check box.
To archive the Maven POM file along with Maven artifacts, select the Include generated POMs check box. To retain the most recent artifacts, select the Discard old artifacts check box.
-
Click Save.
Archive Artifacts
If you want builds of a job to archive artifacts, you can do so as a after build action. Once archived, you can download the artifacts manually and deploy them. By default, artifacts of a build are kept as long as the build log is kept.
-
Open the job’s configuration page.
-
Click the Post Build tab.
-
Select the Archive the Artifacts check box.
-
In Files to archive, enter space or comma separated list of files (with path) to archive. You can use wildcards too. Example:
module/dist/**/*.zip
.To enable automatic validation for file masks, select the Enable auto validation for file masks check box.
-
In Excludes, enter space or comma separated list of files (with path) to exclude.
A file that matches the exclude pattern isn’t archived even if it matches the pattern specified in Files to archive.
-
To discard artifacts from older builds and save artifacts from the last stable build, select the Discard all but the last successful/stable artifact to save disk space check box. Artifacts from the last unstable build or last failed build are also saved if they are newer than the last stable build.
-
From Compression Type, select the archive format.
-
If your application is a Maven application and you want to archive Maven artifacts, select the Archive Maven 3 Artifacts check box.
To archive the Maven POM file along with Maven artifacts, select the Include generated POMs check box. To retain the most recent artifacts, select the Discard old artifacts check box.
-
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.
-
Open the job’s configuration page.
-
Select the Main tab.
-
Configure the discard options.
-
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.
-
Open the job’s configuration page.
-
Click the Build Steps tab.
-
Click Add Build Step and select Copy Artifacts from Another Job.
-
In Job Name, select the job whose artifacts you want to copy.
-
In Which Build, select the build that generated the artifacts.
-
In Artifacts to copy, specify the artifacts to copy. When a build runs, the artifacts are copied with their relative paths.
If no value is specified, the build copies all artifacts. Note that the
archive.zip
file is never copied. -
In Target Directory, specify the target directory in the workspace where the artifacts are copied.
-
To flatten the directory structure of copied artifacts, select the Flatten Directories check box.
-
By default, if a build can’t copy artifacts, it is marked as failed. If you don’t want the build to be marked as failed, select the Optional (Do not fail build if artifacts copy failed) check box.
-
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 |
|
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:
|
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.
|
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.
|
Abort a build if it’s stuck for some duration |
|
Add timestamps to the build log |
By default, build logs are not timestamped, however you can configure a job to add them to the log.
|
Run a Build
You can run a job’s build manually or configure the job to trigger it automatically on an SCM commit or according to a schedule.
Action | How To |
---|---|
Run a build manually |
Open the job’s details page and click Build Now. You can also run a job’s build from the Jobs Overview page. In the jobs table, click Build Now . |
Run a build on SCM commit |
|
Run a build on a schedule |
View a Job’s Builds and Reports
To view a job’s builds, reports, build history and perform actions such as run a build or configure the job, on the Build page, click the job name to open its details page.
View a Build’s Logs and Reports
A build generates various types of reports and logs such as SCM Changes, test results, and action history. You can open these reports from the Job Details page or the Build Details page.
The following table lists the various types of reports generated by a build. On the Job Details page or the Build Details page, click the report icon to view its details.
Log/Report | Description |
---|---|
Build Log |
View the last build’s log. In the log page, review the build log. If the log is displayed partially, click the Full Log link to view the entire log. To download the log as a text file, click the Download Console Output link. |
SCM Changes |
View all files that have changed in the build. When a build is triggered, the build system checks the job’s Git repositories for any changes to the SCM. If there are any updates, the SCM Change log displays the files that were added, edited or removed. |
SCM Poll Log |
View the Git SCM polling log of the builds that displays the log of builds triggered by SCM polling. The log includes scheduled uilds and builds triggered by SCM updates. In the Job Details page of a job, click Latest SCM Poll Log to view the Git SCM polling log of the last build. |
Test Results |
View the log of build’s JUnit test results. To open the Test Suite details page, on the Test Results page, click the All Tests toggle button and click the suite name in the Suite Name column. To view details of a test, on the Test Results page, click the All Failed Tests toggle button and then click the test name link in the Test Name column. You can also click the All Tests toggle button, open the test suite details page, and then click the test name link in the Test Name column. |
Audit |
View the Audit log of user actions. You can use the Audit log to track the user actions on a build. Use the log to see who performed particular actions on the job. For example, you can see who cancelled a build of the job, or who disabled the job and when was it disabled. |
View a Project’s Build History
The Build History page displays builds of all jobs of the project.
Tip:
To sort the table data by a column, right-click inside the build history table column and select the sort order from the Sort context menu.View a Job’s Build History
A job’s build history can be viewed in the Build history section of the Job Details page. It displays the status of the running builds, and completed job builds in descending order (recent first) along with their build numbers, date and time, and a link to the console output of the build.
The build history shows information abut how the build was triggered, its status, build number, date-time stamp, a Console icon to open the build’s console, and a Delete icon to delete the build.
To review the build history, note these points:
-
In the Build column, an * in the build number indicates the build is annotated with a description. Mouse over the build number to see the description.
-
The list doesn’t show the discarded and deleted jobs.
-
If a running build is stuck in the
Queued
status for a long time, mouse over theQueued
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.
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.
-
Open the job’s details page.
-
Click Latest Artifacts.
To download artifacts of a particular build, n the Build History, click the build number, and then click Build Artifacts.
-
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.
-
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 |
|
Disable email notifications of the job to all subscribed members |
|
Build Executor Environment Variables
When you run a build job, you can use the environment variables in your shell scripts and commands to access the software on the build executor.
To use a variable, use the $VARIABLE_NAME
syntax. Example: $BUILD_ID
.
Common Variables
This table describes some common environment variables.
Environment Variable | Description |
---|---|
|
The current build’s ID. |
|
The current build number. |
|
The full URL of the current build. |
|
The build output directory. |
|
The name of the job. |
|
The unique number that identifies the current executor (among executors of the same machine) that's running the current build. |
|
The HTTP proxy for outgoing connections. |
|
The HTTP proxy host for outgoing connections. |
|
The HTTP proxy port for outgoing connections. |
|
The HTTPS proxy for outgoing connections. |
|
The HTTPS proxy host for outgoing connections. |
|
The HTTPS proxy port for outgoing connections. |
|
The name of the current job. |
|
The full URL of the current job. |
|
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. |
|
Specify the pipe ( | ) separated list of domain names or the IP addresses for which the proxy should not be used. You can also specify port numbers. |
PATH |
The PATH variable set in the build executor specifying the path of executables in the build executor. |
WORKSPACE |
The absolute path of the build executor's workspace. |
Software Variables
Environment Variable | Description |
---|---|
|
The path of the Oracle ATG |
|
The path of the Oracle ATG root directory. |
|
The path of the Gradle directory. |
|
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, |
|
The path of the Hudson home directory. |
|
The full URL of the Hudson server. |
|
The path of the Node.js home directory. |
|
The path of the Node.js modules directory. |
To access JDeveloper or SOA, use these variables.
Software | Variables |
---|---|
JDeveloper |
|
SOA |
|
- Use
JAVACLOUD_HOME
variables to access the Java SDK - Use
ORACLE_HOME
variables to access JDeveloper - Use
MIDDLEWARE_HOME
variables to access Oracle Fusion Middleware. TheMIDDLEWARE_HOME
directory includes the JDeveloper installation directory, WebLogic Server installation directory, and the Oracle Common library dependencies. - Use
WLS_HOME
variables to access the WebLogic server binary directory bundled with JDeveloper
Tip:
-
You can run the
env
command as a Shell build step to view all environment variables of the build executor. -
Some Linux programs, such as curl, only support lower-case environment variables. Change the build steps in your job configuration to use lower-case environment variables.
Example:
export http_proxy="$HTTP_PROXY" export https_proxy="$HTTPS_PROXY" export no_proxy="$NO_PROXY" curl -v http://www.google.com
Software Installed on the Build Executor
Various software, such as JDeveloper, Xvfb, and Node.js, are installed on the build system and are available to the build executors when running on Oracle Cloud.
Executables from the software bundles are available on the builder's PATH
variable, which is set to/usr/bin,
and can be invoked directly from the Execute Shell build step. You should use the PATH
variable and other environment variables to access the installed software.
This table lists software available in the software catalog, in addition to the software installed by default.
Software | Version |
---|---|
Ant |
1.9.6 |
Findbugs |
3.0.1 |
Firefox |
45.x |
Git |
1.7.1 |
Gradle |
2.x 3.x 4.x |
Java |
10.x 9.x 1.8.x 1.7.x 1.6.x |
Maven |
3.3.3 |
Node.js |
0.12.x 4.x 6.x 8.x |
Node.js – grunt |
0.4.5 |
Node.js – gulp |
3.9.0 |
Node.js – grunt-cli |
0.1.13 |
Node.js – gulp-cli |
0.3.0 |
Node.js – bower |
1.7.7 |
Node.js – oracledb |
1.7 |
Node.js Driver for Oracle Database |
12.1.0.2 |
Oracle ATG 11.1.0.1 |
11.1.0.1 |
Oracle Developer Studio 12.5 |
12.5 |
Oracle Instant Client 12c |
12.1.0.2.0 |
Oracle JDeveloper 11g |
11.1.1.7.1 |
Oracle SOA Suite 12c |
12.2.1.1.0 12.1.3.0.0 |
SQLcl |
17.4.0 |
Python |
2.6.x |
Python – pip3 |
8.1.x |
Ruby |
1.9.3p448 |
SFTP |
yum:latest |
Xvfb |
1.15.0 |
To know about the environment variables that you can use to access the software, see Build Executor Environment Variables.