A guide to diagnosing CI job failures

This post is brought to you by Eric Kintzer, Salesforce Architect and one of Gearset’s Community Advisors.

A common use of Gearset is to run Continuous Integration (CI) jobs between your source control and a reference org (let’s say, the CI org) to check that your changes:

• Are deployable (with no missing components)
• Don’t break regression tests

Gearset 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 “Error” 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’t 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’s 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>

Gearset 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 Gearset error doesn’t 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 “recent” in you or your teammate’s 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 30-day free trial of Gearset’s Salesforce CI/CD solution. And to learn more about CI/CD for Salesforce check out Gearset’s free CI/CD ebook.