CI Job Results
  • 5 Minutes to read
  • Contributors
  • Dark

CI Job Results

  • Dark

The CI JOBS screen is best viewed when the zoom setting is set to 80% on your chrome/firefox browser.

The CI JOB RESULT is the page where you can:

  • create a new CI job
  • trigger a new build for your CI job
  • find the build/deployment details, SCA report, etc. for your CI buildsCI Job Results

Deployment Workspace

View the builds that are in the deployment queue on the Deployment Workspace on the right side of the page.Deployment workspaceQueued Builds

Important Notes:
Different scenarios in which the queued build will be seen in the Deployment Workspace:
  • Two CI Jobs have the same destination Salesforce org: In this scenario, the first initiated CI Job will be processed and the other CI Job will be in a queue
  • The queued CI Jobs will auto-refresh every 40 seconds and will be executed based on the CI Job scheduled. 
  • Agent configured in your environment: If the agent parallel process limit is reached, then the job will be added to the queue.

Build Details

For each Build, the following information is displayed:

  • Build Label: Displays the names of the build that has been created.
  • Build Date: This shows the date and time on which the process was created and run.
  • Build Number: Build numbers for each Job in reverse chronological order. 
  • Abort (if the build is in progress): Abort the ongoing CI job deployment and test case execution. This option will be available only if the build is in progress.
  • Build Information (): View the complete build information or download them to your local machine. The file downloads in ZIP format.CI Job Results
  • Build Status: View the status of the build triggered (success/in progress/failed). There is a provision to download the build log report from the log screen.Build Label

Warnings, Changes, Check-ins, and SCA

Hover your mouse over () icon under the Build Details to find out more two to three choices depending on your configured job:Build Details


View the warnings that occurred when builds were deployed. If no warnings are found, the 'No Warnings Found' popup will appear.


The Changes screen will display the following info:

  • Metadata Changes: This tab will include a list of all metadata changes made in the current build.
  • Destructive Changes: The destructive changes components will get listed on this tab (Learn More)

  • File Changes: All the newly added/modified metadata files will be listed on this tab. The number of lines being added or deleted will be properly highlighted. The lines highlighted in RED color indicate those are deleted from the metadata files and for GREEN color indicates those are newly added/updated.
    Also, the user can download individual metadata file change report using the Download icon.
  • Check-ins: The user can get a comprehensive check-in summary for their CI job in this tab. This displays all the revisions that are included in the build cycle.
    Points to Remember:
    • For the files with huge content, the differences in the metadata files will not be shown on UI, however, the user can download the diff on their local machine and view them.
    • Excluded metadata members are too not shown under the File Changes tab. Also, for the SFDX Jobs build with a single source folder, the File Changes tab will not show other folder files even if exists in the revisions.
    • For builds triggered earlier, the user may not find the File Changes tab.
    • Recently triggered builds will now have File Changes along with Check-Ins view.
    • For Version Control as GIT, the delta is being generated with git diff to pick all the required changes (in case of lazy commits created using gated merge). So, there could be a chance of seeing a discrepancy in the files with Metadata Changes and Check-Ins.
    • For Version Control as GIT, the delta generates with git diff to pick all the required changes (in case of lazy commits created using gated merge). However, there may be a slight chance of seeing discrepancies in the files with metadata changes and Check-Ins.
    • Builds triggered with the GIT repository in between the two weekly fixes will not show all the revision details in the Check-Ins. Instead, all the changed files are bounded to a single HEAD revision of that build.
    • Parent Revisions in the Check-ins tab will be blank for the jobs that were run before the version 22.1.18-RELEASE.

SCA (Static Code Analysis)

Static Code Analysis is usually performed as part of a Code Review and is carried out at the Implementation phase of a Security Development Lifecycle (SDL). Static Analysis tools such as ApexPMD and Checkmarx continuously detect and report on data flow problems, software defects, language implementation errors, inconsistencies, dangerous usage, coding standard violations, and security vulnerabilities.

SCA will have information for both PMD and Lint report (Lint report will display information about AuraBundle components files only). This report will have info about the files that were reviewed and the related violations that occurred. Click on each file to view its related violations that will appear at the bottom right side of the page. If you click on any violation, it will take you to the respective line (in the black screen on the right side) where such violation occurred. 

Static code analysis

Apex class

Link report

Deployment Details

Under the Deployment details, you can view the below information:

Deployment details

  1. Deployment Status: View the status of the deployment triggered.
    Validate deployment is successful
    Validate deployment is failed
    Deployment is successful
    Deployment is failed
  2. Deployment Log: View the detailed deployment log report on UI or download them to your local machine.
  3. Quick Deploy: View the status of the quick deployment performed or re-run the quick deployment again
  4. Rollback: The rollback feature is very useful to roll back a deployment as soon as you realize that something went wrong with the CI job or you accidentally deploy something unwanted. (Learn more)
    Rollback Prerequisites:
    Enable the Rollback checkbox while creating a CI Job (in the Deploy section).
    • The Rollback Validation () icon denotes the rollback is successfully validated and rollback can be triggered once again. This icon can be seen only if the Validate Rollback option is chosen during rollback.
    • Re-run Rollback: While running the rollback again, you can choose the metadata members that you want to perform the rollback. If there are any metadata members that you no longer required and would like to delete from your org, in such case you can perform the destructive changes (pre/post) to such components. The selected components, i.e., excluded components detail can be found in the Rollback Log.

Deployment Reports

You can download the deployment, quick deployment, or rollback reports for your build via hovering the mouse over () icon under the Deployment Details section.

  • Deployment Reports: Displays the detailed deployment report. A sample screenshot is attached below.Deployment reports
    For CI jobs builds that are older than 30 days, deployment, quick deployment or rollback reports will not be accessible.
  • Quick Deployment Report: View the quick deployment report.Quick deployment report
  • Rollback History: View the detailed rollback history report here. Additionally, the user can also view the rollback log and report on this screen too.Rollback history

Post Activities

View the post-deployment activities that were triggered, log report, and post-activity status i.e. success or failure.

Post Activity StatusCI JobEnvironment ProvisioningData LoaderMergeJenkins Job
SuccessCompletedSuccessCompletedMergedSuccess or unstable
FailedAny other status except completedAny other status except successAny other status except completedAny other status except mergedAny other status other than Success or unstable

Functional Tests

View the success and failure test percentage report for your build triggered.

Apex Tests (Coverage)

Under Apex Tests (Coverage) tab, view the code coverage report here. The code coverage report provides information about the apex tests that are run, the classes that are covered, and the assertions that have failed and provide a percentage of the code that is covered by the test execution for an org.

Was this article helpful?