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

Only display active branches when displaying branches from a bit bucket cloud repository

Page Layouts use the <excludeButtons> element to indicate the presence or absence of standard buttons on a layout.

But this element appears in an arbitrary order when retrieved. Unlike other metadata which gets canonicalized by sorting alphabetically.

Gearset could sort these elements to avoid the random order causing random diffs to appear in metadata comparisons when in reality there is no difference.

I frequently deploy from our on premises GitLab repo. It would be great to have the ability to set the default branch it goes to. It would be one less click for repetitive steps

I really love using Gearset. It would be great if we have a plugin in there to integrate Gearset and SonarQube to display Static Code Analysis and Test Coverage in Sonar. I had tried this through CircleCI and it requires lot of configuration and we need write code to create and maintain the connection.
Whenever there is an update to the GIT Master it has to Initialize the Sonar Scanner and it'll run some tests and display results in SonarQube.
Thanks!

When comparing Custom Objects that contain the managed custom fields there is no way to suppress the managed custom fields. The fields would show up in the comparison results even without being requested. The problem analyzers then highlights and remove these managed custom fields.

This is cumbersome when repeated and makes finding genuine differences we care about more difficult.

From the problem analyzers, it sounds like Gearset is able to identify the managed custom fields. Therefore could there be an option under [Include managed package] in the Custom Filters that allows the suppression of known managed fields in comparison results?

Currently, metadata from Unlocked Packages show up when comparing against an org. This leads to duplication of metadata in source control repositories (correct DX package repository and incorrect monolithic, "happy-soup" repository).

Using the Package2Member Object (Tooling API), it is possible to deduce whether or not a metadata item is part of an unlocked package. Therefore, it should be possible to ignore some or all unlocked packages (or any Package2 package), in a similar fashion to the way Gearset filters allow inclusion or exclusion of managed packages.

It would be nice to capture whatever test classes ran for code coverage deployment of classes/triggers in the deployment summary in the Test Results section. You already have a section for this test results so why not add the class names used in the report. We have come across many classes deployed without their appropriate test classes and it is hard tracking/documenting which test classes were used to deploy these as there are no documentations in the class.

Allowing data deployments in CI jobs. So that configurations in third party apps and B2B Commerce can be deployed as part of CI.

When deploying code, it would be nice to have an option of having an exclusion list of test classes to not run.

Use case on Difference Viewer:

search on `profilerecordtypevisibility' (or use metadata filter and check Profile: Record Type Visibility)

Results
Unless the difference viewer already has the Profile(s) expanded for their components, you get no results

Desired behavior -- Search on components within Profile should show results; even if search takes longer

The ability to use this product for CI/CD and various other use cases in the US federal space would be a huge win for many agencies. I know the FedRAMP process is quite arduous, but the contractual potential here is pretty massive.

Right now, Gearset is down and we cannot use it. It would be good to have a trust.gearset.com site that shows what is going on and what the team does to fix the issue...

When pushing work flow rules and associated actions, if you do a compare with only workflow, then gearset prompts an error indicating that the target objects do not exist in the destination and that the rules should be removed from the package for the deployment to be successful. In this case, it told me Account, Event and Opportunity do not exist in the target. Including other metadata from the referenced fields resolves the issue.

For example, deployments to a production environment should only come from the master branch of our git repository

When connecting a source code control system, quite often an integration user account is used that may also be used for other parts of the enterprise. Please allow admins to restrict the available repositories and branches so that users can only run comparisons for the branches they should actually have access to.

we have a custom field we use that ties to a release number. It would be great if as an additional option to selecting tickets, access this field, set the value (in this case our release number) and have gearset pull all related requests in.