Building a Package from Version Control

How to build a package from version control.

The CI JOBS screen is best viewed when the zoom is set to 80% on your Chrome/Firefox browser.

Overview

Convert and package your version-control files to Salesforce Metadata components based on a Start Revision. You can also configure an ALM project and sprint to include only revisions tied to a user story and its status.

Procedure

1. Log in to your ARM account.

2. From the top navigation pane, navigate to Create New > New CI Job.

   

   New CI Job button
3. Choose the tile: Package from Version Control.

   

   Package from Version Control tile
4. Enter a descriptive Job name.

5. Add a brief Description.

6. (Optional) Choose a Group to organize the job, or click + to create one.

7. The configuration page is divided into sections explained below.

Build

1. Select your Version Control system – ARM supports Git, SVN, and TFS.

2. Choose the Repository and Branch.

3. Under Build Using, pick one option:

   • Baseline Revision – Enter a revision manually or click Edit () to select it from a list.

     

     Select baseline revision

     

     Baseline revision pop-up

Important Notes:

1. For the first CI job, you must choose a Baseline Revision.

2. Get Latest HEAD points to the last commit in the current branch.

• Time Range – Specify a period so ARM fetches only revisions in that window.

  

  Time-range selector

Additional options in the Build section

1. Status Check API – Check the status of APIs running for the CI job.

2. Pull Request – Create a pull request for this job.

3. Merge Request – Create a merge request for this job.

4. Map ALM Project – Configure ALM (e.g., Jira) work-item statuses to include in the build.

Important note: Build Using – Baseline Revision/Time Range and Trigger Build on Commit are unavailable when Map ALM Project is selected.

1. Trigger Build on Commit – Launch a build whenever changes are committed to the branch.

   • Process commit revision via hook only – Visible only for Git-type repos. When enabled, the build packages changes from the commit revision received via webhook up to the branch head, ensuring no commits are skipped.

Note: If you commit both _nCino record-based config_ and _Salesforce metadata_ files to the same branch, certain Git systems may trigger unnecessary builds. This happens when the **Build on commit** option is enabled and changes occur only in an irrelevant folder.
 

1. Incremental Build – Fetch only metadata changed since the last successful deployment, dramatically reducing build time.

Important note: Incremental Build also works when validating Deployment Jobs.

1. Prepare Destructive Changes – Delete unwanted metadata from the destination org before deployment.

2. Run Static Analysis Report – Identify code-quality issues before production.

   

   Static analysis options panel

   • Apex PMD / Checkmarx – Set criteria such as date range and Priority. If the priority threshold is not met, the build is marked unstable.

     

     Criteria for Apex PMD and Checkmarx
   • CodeScan / SonarQube – Choose to scan all metadata or only newly added components, then set a Priority.

     

     Criteria for CodeScan and SonarQube

     • Run on all supported metadata types – Scan every retrieved component.

     • Run on newly added supported metadata types – Scan only newly added components.

     • Run on all supported metadata types from the full source – Scan the entire branch.

       

       Scope options for supported metadata types

     For details on running Static Code Analysis in CI jobs, see this guide.

3. Additional Profile Packaging Options

   • Remove Login IP Ranges – Omit IP-range restrictions from profiles.

   • Remove System and User Permissions – Omit profile permissions from deployment.

4. Exclude Metadata Types – Skip metadata you don’t need in the build.

**Important note**: To set exclusions globally, open **My Account > My Salesforce Settings**, choose **Exclude metadata types**, and select the types to skip.

Notifications

Send email notifications on build success or failure.

Notification recipient list

Schedule

• Daily – Run every day at the chosen time or interval.

• Weekly – Run on selected day(s) and time.

• No schedule – Save the job and trigger it manually.

For credential-usage details across CI job types, see the FAQ.

What Next?

After saving the job, ARM redirects you to the CI Job Results page, where you can trigger the first build.