When deploying a branch to a Salesforce org where there is a managed package version mismatch in the file metadata, it would be nice to be able to bypass this discrepancy as there are occasions where there may be a newer package version in a lower/sandbox org and an older package version in a higher/production org.

If you deploy Settings | Search there are entries for <searchSettingsByObject> with sub-element <name>myFoo__c</>

if the target does not include the custom object myFoo__c, Gearset doesn't flag this as a warning with a default fix to exclude the <searchSettingsByObject>

When you delete a custom object, the Repo Cleaner should remove the references to that custom object in the Settings metadata type - specifically SearchSettings | <searchSettingsByObject>

Otherwise, it becomes impossible to deploy Search Settings via CI jobs

when Gearset Analyzer tells you that you should consider removing a permission from the deployment, it displays the API name of the permission but often this doesn't tell you what item in the Setup UX you need to check on

example:

ContentHubUser is actually the permission for Files Connect Cloud My suggestion is that Gearset take advantage of this resource http://www.fishofprey.com/2020/10/mappings-between-salesforce-permission.html and display both the API name and the UX name in parens - such as :
ContentHubUser (Files Connect Cloud)

Currently, attempting to deploy a named credential will fail as a "password is required for the specified authentication protocol".

This can mean manual work if you have a lot of CI deployment jobs to sandboxes or annoyance if you expected to be able to deploy it.

It'd be great if an analyzer existed that would alert/warn the user about it going to fail and unable to be deployed (suggest removing it from the package)

In a CI job : Validation shown as success & Deployment shown as success. But actually no workflow deployed due to it being removed in the Problem Analyser.

The Problem Analyser triggered due to the (standard) object, that the workflow depends on, not being in the comparison results.

In a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap - problem analysers should never fire on object dependency.

The metadata for EInstein Bots includes a tag called "botUser" that contains the username of the user you've specified to run the bot as. Because it contains a username, the deployment fails unless you have the exact same username in both environments.

My current workaround is to deactivate the bot, remove the running user (which removes the botUser tag), deploy, then reset the changes that I made.

Can we get a problem analyser that will detect and remove this botUser tag so that the deployment will complete?

CI job : Validation shown as success & Deployment shown as success.. but actually no WF deployed. Saying Opportunity object doesn't exist in target just because it was not selected in the components. in a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap.

In order to make deployments more repeatable between orgs please allow a way to save the selection of deployment analysis suggestions an d list of test classes with a package. With a large package it can be difficult having to document or remember the same selections used in deployment to UAT org for Production deployment.

The dependency crawler that GearSet offers is one of its biggest strengths. A lot of manual labor can vanish at the click of the button. Best example would be the addition of all relevant Picklist fields when a Record Type is added to the Selected Items.

Sometimes deployments still fail, and in particularly big orgs the dependency crawl takes ages, each time I have to rerun the problem analysis.

A way to add the metadata that was auto-added prior to the deployment to the list of Selected Items to make future analysis faster would be greatly appreciated.

Ensure that Apex Classes imported in LWC javascript files are included in dependencies.

Right now, if you include a lightning page in a deployment and do not include any of the components on the page (list view, report chart, etc), the problem analyzer finds no issue with it.

Even if the report is not in the target or is included in the compare, the analyzer always finds no issue with the lightning page.

It'd be great to have it function like other metadata where it would alert you to missing components in your package (by suggesting to include all referenced list views, reports, etc on the lightning page).

Currently, when there is an error with an XML metadata file (usually introduced by git merges), Gearset will produce an error, either in the Initializing Comparison, or Checking Deployment stages, stating simply that "An unknown error occurred."

If Gearset instead ran the XML from source control through an XML validator using the Partner WSDL XMLSchema, then we could get file-level validation errors if the XML doesn't conform to what Salesforce's Metadata API will accept.

e.g.:
$ xmlstarlet val -e -s ~/Downloads/salesforce-schema.xml force-app/main/default/profiles/Marketing.profile-meta.xml
force-app/main/default/profiles/Marketing.profile-meta.xml:17108.15: Element '{http://soap.sforce.com/2006/04/metadata}field': This element is not expected.
force-app/main/default/profiles/Marketing.profile-meta.xml - invalid

It would be great if Gearset could run static code analysis on JavaScript as well as Apex when deploying Lightning Components.

Add during problem analysis:

Remove the "run as specific user" completely from the dashboard prior to deployment (set the options to "Run as logged-in user"). Deploy, then change it back to whatever you need. Based on https://developer.salesforce.com/forums/?id=906F0000000DCJPIA4