Build a package from Version Control
Last updated
Was this helpful?
Last updated
Was this helpful?
Convert and package your version control files to components based on a "Start Revision." Additionally, configure an ALM Project and Sprint to only include revisions based on a user story and its status.
Log in to your ARM account.
From the top navigation pane, navigate to Create New > .
On the next screen, give the job a descriptive name in the Job Name field.
Add a brief description of the current CI job.
To group your CI job for easier identification, choose the group from the dropdown. You can create a new group using the "+" symbol and assign your current and subsequent CI jobs to a group.
Here, the user interface is in different sections; we will cover each one of them separately.
Select the Repository and the Branch.
Under the 'Build Using' dropdown, there are two different options to choose from:
Time Range: This option allows you to create a CI job using a timeline. You need to specify the time period from when the revisions will get fetched. This improves the usability of our CI server and helps build a package based on time rather than commits.
Status Check API: This allows you to check the status of the APIs being run for the CI job.
Map ALM Project: (Ex: Jira) Configure work item type status in ALM type to include in the build (under the ALM section).
Important Note: Build Using - Baseline Revision/Time Range and Trigger Build on Commit is not available if the 'Map ALM Project' option is chosen.
Trigger Build on Commit: A new build is triggered when changes are committed to the mapped version control system.
Process commit revision via hook only: This option is visible only for Version Control as GIT (Enterprise BITBUCKET, BITBUCKET, VSGIT, GITLAB, GITHUB) type. Upon selection, the build agent will read the commit revision number and generate a package from that revision number to the branch head. Let’s take the following scenario: Two developers (Developer A and Developer B) are both working on the same code base.
Developer A committed some changes to its local repository at 10 am this morning but did not push the changes to the remote repository.
Developer B also performed some changes in the code, but he pushed the changes into the remote repository by 10:05 am this morning. So, when ARM builds get triggered by webhook, Developer B's changes will be packaged and deployed, and the code gets updated with the latest revision. However, Developer A's changes are ahead of Developer B's, so ARM will show no modifications for the build, since Developer B's changes are in the HEAD position. To overcome this scenario, ARM has an option to "Process commit revision via hook only." This will prepare the build from the revisions of Developer A to the HEAD revision of the branch, thereby ensuring no commits are skipped in the ARM cycle.
Note: If you’re committing both nCino Record-Based Config files and Salesforce Metadata files to the same branch—even though they’re in separate folders—AutoRABIT may encounter an issue with certain Git-based version control systems. Specifically, AutoRABIT is unable to determine which folder's content has changed, leading to unnecessary build triggers that won't pick any changes if changes are in an irrelevant folder when the 'Build on commit' option is enabled.
Run Static Analysis Report: This will identify potential software quality issues before code moves to production.
For ApexPMD and Checkmarx: ARM allows you to set the criteria for running the ApexPMD static code analysis (SCA) tool. This means running for all the apex classes or stating the period when it will run. Also, you can set the priority, which means if the priority set is not achieved, the current build is unstable. This helps in reporting the code quality of the developer team.
For CodeScan and SonarQube: Set the criteria for running the CodeScan or SonarQube tool, whether to run on the supported metadata types from the full source or to run on the newly added components. This means running for all the apex classes or stating the period when it will run. Also, you can set the priority, which means if the priority set is not achieved, the current build is unstable. This helps in reporting the code quality of the developer team.
Run on all supported Metadata types: Analysis is performed on all the supported metadata types. For example, if the build includes 2 classes and 2 triggers, then the analysis will run on all the supported components that are retrieved for those 2 classes and 2 Triggers in the build.
Run on Newly added supported Metadata types: Analysis is performed only on those components received during build retrieval. For example, if there are added as well as modified components in the build, then the analysis runs on the newly added components, not on the modified components.
Run on all supported Metadata types from the Full source: Analysis is performed on the entire branch, including all supported metadata types, regardless of any build changes.
Additional Profile Packaging Options:
Remove System and User Permissions: System permissions control a user’s ability to perform tasks that apply to their VCS or Org. To not deploy this permission, select this option.
Exclude Metadata Types: These exclude the metadata no longer required for build/deployment. To avoid fetching unwanted metadata types during a CI job, ensure that you have excluded them. If the 'Exclude Metadata Types' checkbox is not checked, all metadata types will be chosen. That globally excluded metadata will be auto populated if you select this option.
Send email notifications to selected users on the success or failure of a build.
Allows you to schedule the process at which it must run.
Daily: The process will run every day at the scheduled time or time interval set.
Weekly: The process will run weekly on the scheduled day and time.
No schedule: The process will only get saved, and you can run it when required.
Choose the tile: Package from .
The first step is to choose your System. Currently, ARM supports Version Control Systems like GIT, SVN, and TFS.
Baseline Revision: Enter the baseline revision number manually or click on the Edit () icon to select the baseline revision. A new pop-up window appears. From the list displayed, choose the required baseline revision number.
: Creates a pull request for the current CI job if opted.
: Creates a merge request for the current CI job if opted.
Incremental Build: Incremental builds are important for managing continuous builds for . Incremental builds substantially decrease build times by avoiding the execution of previous metadata that is not needed. This will fetch all the metadata changes beyond the selected Baseline Revision till the successfully deployed revision to the destination org. On the next CI Job run, the previous Baseline Revision automatically gets changed to the successfully deployed revision. Accordingly, there will be a substantial increase in build-time performance for large-project incremental builds compared to when changes to a single file or a small number of files are performed.
Prepare Destructive Changes: The pre-destructive changes option allows users to delete unwanted fields or metadata components from their destination before the deployments begin.
For more information on running Static Code Analysis in CI Jobs, refer .
Remove Login IP Ranges: If you want to log in with a , you have an option to restrict IP ranges. Upon selection, login IP details will not be deployed to Salesforce Org.
Important Note: To set this option at a global level, go to the 'My Salesforce Settings' section on the page. Next, select the metadata types to exclude. This is reflected in all CI jobs created from this point forward and across other modules as well.
For more information on Credential Usage for different types of CI jobs, refer .
Once you fill in all the details for your CI job, you will be redirected to the page, where you can trigger a build for your CI job.
