On the deployment history page, the column widths are fixed. If you have a value in the "friendly name" column that's over a certain character count, it gets truncated automatically. there is a tool tip to see the full value by hovering, but if you use consistent naming standards for naming deployment packages, this can result in having to hover over many package (i.e. rows) to find the one you want.

if making the column width customizable isn't possible, then making the "friendly name" column character limit longer would be a good start!

When you delete a managed package from VCS by deleting its <InstalledPackage>, Gearset should look for all traces of that managed package in VCS and delete those files/update the metadata

The <InstalledPackage> file identifies the namespace - eg. SomePkg, and Gearset should be able to remove files that start SomePkg__ as well as delete/edit metadatablocks within other files that reference SomePkg__c.

It is extremely tedious to remove managed package metadata from VCS otherwise; especially if the customer opted to put a lot of managed package metadata in VCS (perhaps by accident)

Lets say multiple vendors are working on different environments and done the deployment across all the lower environments using their own Gearset. But coming to the production org. internal team will be performing the deployments using internal Gearset. So Instead of recreating the deployment draft again, it would be very useful internal team can reuse the draft created by vendor in different Gearset environment.

This could be automatically prefixed to friendly name of the deployment.

Sth like "000035"

Could be a simple counter (that I see you have implemented "This is your NNth deployment...").

If the autonumber would pop up automatically then I would not need to figure out a reference and type it myself.

Currently, info that potentially could be used: datetime (too long) , url (way too long)

Currently successful deployment notifications send every success to the specified addresses. Having the ability to specify the source would eliminate the unnecessary notifications to those addresses. We have a use case in which we only wish to send notifications for successful deployments to our production source.

Would it be possible to get a feature where we can download the fields into a csv file?

It would be great to see the chosen data hosting option for an account in the 'My Account' area. Without it security audits will not be able to verify what setting was chosen and will have to rely on documentation held elsewhere.

Currently there is no feature to prevent users in creating their own connections within Gearset.

We need users to follow the permission that was setup on the shared connection. We have only 2 users that have the approval to deploy code from a sandbox to production. As they can set up their own connections then this bypasses our restriction

Having a permission only available to the Enterprise user or a user approved to create connections and delegate access would prevent the bypass of access permissions

There is no support for Wave Recipes currently and we are not able to deploy dashboards via Gearset and Continuous Integration.

Currently, if your deployment fails you have two options:

1. Click "back to results"
2. Click "new comparison"

Going with option 1 means it needs to re-load the comparison and then click next and re-run all the analyzers again which can take a varying amount of time depending on the size of the comparison/deployment.

In situations where the deployment failed, but the fix is to change something in the org manually - it'd be great to have an option to simply "retry deployment" from the failed deployment screen and skip the various screens and re-loading.

Be able to delete a comparison run with wrong filters or just keep the latest comparison

It would be great to be able to export the list of unit tests and their respective code coverage in a csv file for further internal processing.

Users should be able to specific and save test classes in the comparison stage so they can be saved in draft deployments. Seems like a waste of extra steps to unclick tests and select tests over and over as you work through a deploy.

also when deploys are combined, they would get all the test classes, again, saving lots of time.

It seems based on the below doc

https://docs.gearset.com/en/articles/3624846-what-does-gearset-s-repo-dependency-cleaner-do

That the repo cleaner will remove permission references related to the following deleted items:

Apex Classes
Tabs
Apps
Object Permissions
Field Permissions

Missing from that list is Apex Pages. It'd be great to have that included to clean up references to the deleted page without having to re-run a 2nd comparison for source control.

The idea is to validate feature branches in repo. For doing this it's necessary to allow specifying source branch by pattern (like feature/*) in "Add CI validation job" menu. The validation should check whether the code breaks the scratch org creation or not. This is valuable due to fragility of scratch org creation process (sfdx force:source:push).