Do you sometimes feel that Gearset is not following the definition in your
package.xml below not returning the comparison results you expect?
This article explains how Gearset reads your
package.xml for comparisons and CI jobs.
How does Gearset read the package.xml?
Gearset will only read and understand the top-level metadata types referenced in the
package.xml. These are specified by the Salesforce Metadata API, and are the metadata types you can select in a custom metadata filter.
Gearset will recognise the
Custom object metadata type and its named members, but will not recognise sub-components like
Record type or
List view in your
package.xml. This can be the reason that even though you have a metadata type (e.g.
Custom field) specified in your
package.xml, you aren't seeing it in the Gearset comparison result. The solution is to specify the top-level metadata type instead (e.g.
Note for SFDX format Git repositories
If the repository is in SDFX format, Gearset does not use the
package.xml file to filter the comparison results.
Metadata filter and package.xml
The metadata filter determines what is requested and downloaded from your org to present in the comparison results. The
package.xml filter takes the metadata info returned from the org and further filters the rows, to only show you the items (and associated sub-components) specified in your
Therefore, if the
Filter comparison by package.xml is ticked, the Gearset comparison results will only show items:
- included in your metadata filter, and
- that have the top-level metadata type referenced in the
Filter comparison by package.xml is unticked, or if the
package.xml does not exist in your repo, the Gearset comparison results will show all items included in your metadata filter.
If there are further questions about this topic not covered by this article, please don't hesitate to ask us in the in-app chat!