91导航

This post is brought to you by , Salesforce Architect and one of 91导航鈥檚 Community Advisors.

A common use of 91导航 is to run Continuous Integration (CI) jobs between your source control and a reference org (let鈥檚 say, the CI org) to check that your changes:

• Are deployable (with no missing components)
• Don鈥檛 break regression tests

91导航 runs a comparison between the source branch and the CI org (no different than any other comparison) and then deploys the changed metadata and runs the tests specified in the CI job setup. CI jobs can be validation-only or full-on deploys.

If you get errors, the View History button on the CI job run lets you see what went wrong to help you fix any issues just like any normal deployment.

But wait - the CI job failed but no errors are shown!

Sometimes, the View Errors button is disabled and it looks like the CI job failed before even getting out of the starting gate:

Your first step is to hover over the ochre-colored 鈥淓rror鈥� oval in the Results column, as shown below.

Errors and their resolution

Error parsing package.xml manifest

A common reason for this is you messed up editing the package.xml file in your source control branch. Perhaps you were trying to edit the package.xml version and you didn鈥檛 create proper XML (e.g. unbalanced opening/closing tags).

Here are a couple of contrived examples where this could happen:

46<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
  ...
 </types>
 <version>45.0</version>
</Package>

In the above, when the distracted user thought the cursor was on the 45 but instead was at the front of the file and then changes were saved (committed) to the branch without double checking.

Or perhaps:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
 <types>
   <members>Account<members>
</types>
 <version>45.0</version>
</Package>

Here, the package.xml file was edited with a <members>Account<members> instead of a proper closing tag <members>Account</members>.

Could not parse the XML for somefilepath. Error occurred at line nnnnn

In my experience, this comes up when you (or a team member) screwed up resolving a merge conflict. You ended up with unbalanced XML tags. The error line number may not help because the mismatch might not be detected by the parser until the last line of the file.

Here鈥檚 an example I contrived:

<?xml version="1.0" encoding="utf-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata"><custom>false</custom><userLicense>Salesforce</userLicense>
    <classAccesses xmlns="http://soap.sforce.com/2006/04/metadata">
        <apexClass>AccountTestFixture</apexClass>
        <enabled>true</enabled>
    <classAccesses>
        <apexClass>AccountsSelector</apexClass>
        <enabled>true</enabled>
    </classAccesses>
</Profile>

This is an excerpt from Admin.profile (11195 lines). The error occurred when resolving merge conflicts where the first apexClass has omitted theclosing tags. That is, there is...

<classAccesses>
...
<classAccesses>
..
</classAccesses>

91导航 reported the error on line 11195 (the last line of the file) 鈥� nowhere near the real cause of the error because that is where the SFDC metadata API parser finally gave up on matching opening and closing tags.

To resolve, look at your commit history to see where the merge conflict changes were done. XML validators can also help identify the offending mismatched tag as the 91导航 error doesn鈥檛 disclose this. Having CI run as soon as commits to the branch are done using webhooks will also help as the introduction of the error will be 鈥渞ecent鈥� in you or your teammate鈥檚 mind.

Get your CI jobs back on track!

Hopefully this guide can help you understand and fix any abrupt CI failures. You can try out CI/CD for yourself with a of 91导航鈥檚 Salesforce CI/CD solution. And to learn more about CI/CD for Salesforce check out 91导航鈥檚 free CI/CD ebook.