Version Control

What is a Version Control System (VCS)?

Version Control Systems are a category of software tools that helps in recording changes made to files by keeping a track of modifications done to the code.

What are the version control tools supported by ARM?

The following version controls are supported:

• GIT
• TFS
• SVN
  
  

What is GitHub and how does it work?

GitHub is the home for all developers—a platform where you can share code, contribute to open source projects, or even automate your workflow with tools like GitHub Actions and Packages. If you’re just getting started with GitHub, you may know us best as a place for version control and collaboration.

Are Git and GitHub the same?

Git is a version control system (VCS). GitHub is the platform where Git repositories can be hosted and teams can work on them together.

What's the difference between git fetch and git pull?

• git fetch really only downloads new data from a remote repository - but it doesn't integrate any of this new data into your working files. Fetch is great for getting a fresh view on all the things that happened in a remote repository.
• git pull, in contrast, is used with a different goal in mind: to update your current HEAD branch with the latest changes from the remote server. This means that pull not only downloads new data; it also directly integrates it into your current working copy files.
  
  

Why Merge Conflicts happens?

When working in Version Control System such as GIT, users can combine commits from two different branches through an action known as merging. Files are automatically merged unless there are conflicting sets of changes (i.e. the commits update the same line of code differently).

A merge conflict is an event that occurs when your version control is unable to automatically resolve differences in code between two commits.

When there are conflicting changes on the same lines, a “merge conflict” occurs because the version control doesn’t know which code to keep and which to discard.

What is Commit in AutoRABIT?

As you work with your files that are under version control, each change is tracked automatically. This can include modifying a file, deleting a directory, adding a new file, moving files or just about anything else that might alter the state of the file. Instead of recording each change individually, the version control system will wait for you to submit your changes as a single collection of actions. In version control, this collection of actions is known as a commit.

Branching and Merging- what's the difference?

A branch allows you to create a copy (or snapshot) of the repository that you can modify in parallel without altering the main set. You can continue to commit new changes to the branch as you work, while others commit to the trunk or master without the changes affecting each other.

Once you’re comfortable with the experimental code, you will want to make it part of the trunk or master again. This is where merging comes in. Since the version control system has recorded every change so far, it knows how each file has been altered. By merging the branch with the trunk or master (or even another branch), your version control tool will attempt to seamlessly merge each file and line of code automatically. Once a branch is merged it then updates the trunk or master with the latest files.

What are Remote repositories?

Remote repositories allow us to share our changes with other members of the team. They can be on a private server, on a different computer than yours, or hosted on a different service. Wherever yours is hosted, you'll need to be able to sync your local repository with the remote repository frequently. To start sharing changes with others, you have to push them to a remote repository. This will cause the remote repository to update and synchronize with your local repository.

Why merge is getting auto rejected during deployment?

Below are the reasons why ARM rejects your merge request:

• It will be auto rejected if the proper merge criteria are not enabled. The merge criteria must be enabled before you are performing the jobs.
  • Navigate to Admin > My Account > Merge Setting to select the proper merge criteria. Click Here for a more detailed explanation.
• Workspaces is wrongly configured
  • Search for the workspace id which has the name of source & target branch and reset that workspace. Once the workspace reset is complete, trigger a new merge.
• Failed to meet the actual code coverage criteria
  • Please update the merge criteria as needed by disabling code coverage under Admin > My Account > Merge Settings.
    
    

AutoRABIT says, "local and remote repositories is not on same revision", what does it mean?"

There are several possible explanations for AutoRABIT to throw an error "local and remote repo is not on same revision":

1. The local repository is out of date.
2. The branch that contains the commit was deleted, so the commit is no longer referenced
3. Someone force pushed over the commit.
   
   

How long does it take to register a version control branch in ARM?

The actual registration of a branch depends on the data available in your version control repository. Mostly, the registration can be accomplished in a matter of 1-2 minutes, however, in some rare cases, it can take anywhere from 30 minutes to an hour.

Is it possible with ARM tool to have merge approval only for one specific branch and not for others?

We don't have feature to limit approvals to specific branches right now. However, there are a few options that can assist you in obtaining merge approval for a specific branch:

• When performing a merge, make sure none of the options under New EZ Merge > Prevalidation Merge are selected; this allows you to merge without approval.
• Under Admin > MyAccount > Merge Settings, make sure the disable merge self approval checkbox is not selected.
  
  

I can only see the Production org and none of the development instances when I try to do a new EZ commit.

You haven't switched on the skip mapping feature, which is why this is happening. Select "Skip Mappings" from the drop-down menu in My Profile > My Roles.

What is the cause of ARM inability to initiate the auto build on commit, as well as the failure of a GitHub pull request?

1. Allow pull requests and build on commit in your VC repository.
2. To see the external pull request, switch on ARM's auto-sync option.
   
   

Why is ARM rejecting my merge request at the final step?

This is due to the fact that the merge criteria do not match the ARM settings. Before submitting the merge request, configure in ARM to match your needs. Make the appropriate modifications under Admin > Merge Settings.

All merge deployments in ARM fail when I try to deploy code from one sandbox to another. Could you assist me with this?

You won't be able to deploy the code to the target org if all of the profiles objects in the package have access permissions set to "false." It's not an ARM issue; it's a salesforce behaviour.

Change the access permission to "True" in all profile objects and deploy to fix the problem; it should now work.

I am getting space issue with my development team, and they are not able to commit the changes through AutoRABIT, due to this branch creation is getting failed. Why?

• Branch creation seems to fail due to the huge Workspace checkout. I would recommend unregistering the unused branches that are already registered in AutoRABIT so that the base checkout will get deleted and the workspace size will be increased.
• Under Workspaces, there are some workspace IDs where there is Delete button is greyed out and those are the base checkouts it will get deleted only if we unregister those branches. So, ensure if there are any unused branches then proceed with unregistering them in AutoRABIT.
  
  

I have access to the apex class for the profiles, but I am not able to find the updated profile data in AutoRABIT.

The Apex class permissions for the profiles can be committed only when you select both apex classes, profiles metadata members while performing EZ-Commit. Also, you need to select the checkbox "Commit Only Profiles for selected metadata members" on the Commits Summary page to commit only profile changes that contain apex class permissions.

Why does a Git branch not display in the "My version control Mapping list" under "My Profile" after being registered in AutoRABIT?

This is because you haven't given permission to that branch in AutoRABIT yet. Re-register the branch in AutoRABIT by checking the checkboxes next to the GIT lists to whom you want access in the My Profile section.

Why the Profiles/Permissionsets are not getting committed to my development branch during EZ-Commit?

For such a case, there can be three possibilities:

• There are no changes in metadata components between the sandbox and the branch.
• Salesforce is not allowing it
  • Retrieve the permission sets using workbench. If still the permission sets are not retrieved, then it is a limitation from Salesforce. Request you to contact Salesforce Support Team for further assistance.
• Components (StandardField, Report, Dashboard, etc.) related to the Profile/Permissionsets are not selected during commit.
  • Select the appropriate components related to the Profiles/ Permissions object under "Select metadata members" in the New EZ-Commit screen and commit once again.
    
    

How to deploy the Field level Security (FLS) permission from version control to your target org?

Field Level Security (FLS) settings will allow you to restrict the users’ access to view and edit specific fields. In order to deploy the FLS settings from a branch to a sandbox in AutoRABIT, you need to perform the below steps:

• During "EZ-Commit"
  • While committing the changes from a sandbox to a destination branch, commit the custom fields and profiles in a single commit.
• During "Deployment"
  • While deploying the Field Level Security (FLS) permissions from the version control branch to the target org, ensure the custom fields and profiles are a part of the same revision.

What is the functional difference between Release Label Merge and Release Label Deployment

Release Label is a set of commit revisions.

• When you perform a merge using a release label, ARM will cherry pick all the revisions and labels in that release label and consolidate all the changes made to that branch. These delta changes are pushed to the destination branch after the conflicts (if any) have been resolved.

• Whereas, when you perform a deployment using a release label, ARM identifies and uses the latest revision in that Release Label as HEAD. The latest revision is identified based on the commit date. Any files in that revision that may have been modified, added, or deleted, are consolidated including any changes made to those files in other revisions besides the HEAD revision. When the deployment is performed, this consolidated metadata file is retrieved.

While creating a new Release Label, I did not select the 'Create package manifest for Deployment' check box. Can I still create a package?

Yes. If you did not select the check box while creating the release label, you can click on the Create Artifact button on the Release Label Summary Screen to manually create and run the package.

Why can't I click on the 'Create Artifact' button on the Release Label Summary screen?

If the Create Artifact button is unavailable to click, this means that the package has been created successfully and can be used for Deployment. It will also be unavailable if package preparation is In-Progress, and will be available shortly. You can view the status on the Release Label Summary screen. Create Artifact button will only be available if the package has not been prepared or has failed during preparation.

Why am I getting an error while trying to register GitHub repository with SSH?

GitHub no longer allows new RSA keys with SHA-1 signature. Execute the ssh-keygen -t ed25519 -C “sampath.c@autorabit.com” command in the terminal to create a new key, or contact support@autorabit.com for further assistance. Please note that you must create the new key in Linux or Unix, not in Windows. For more information, visit https://github.blog/2021-09-01-improving-git-protocol-security-github/

My commit failed with errors like 'Tip of your current branch is behind' and '[rejected] Partial -> Partial (non-fast-forward)'. Why did this happen, and how can I resolve it?

To put it simply, this was caused because of an expected Git behavior.

Basically, if the commit is rejected with the error message Tip of your current branch is behind, it means that there is another commit that has already been done on top of the target branch.

Let us assume that you have initiated a merge, and while it is processing someone else (other developer) performs a commit on to the target branch. This will modify the HEAD revision, and the merge which had set a HEAD revision would not be the latest HEAD on the target branch anymore. After resolving the conflicts and while committing the merge, this error is displayed.

This merge process will fail and it is not possible to Re-Push because when compared to the latest HEAD revision, it should bring up the conflicts again which is not possible.

You must re-perform the merge so the commit will set up the latest HEAD revision on the destination branch, and process further.