Rollback currently requires the user who did the deployment to enable "Deployment" user access. Instead, it would be helpful if I could use my own user, within the same org, to do the rollback.

This would be helpful if the individual who did the first deployment is unavailable.

Add support to automatically unzip zipped static resources when migrating to a GIT repo and re-zipping when migrating to SF. This would allow me to edit my static resource files without having to manually unzip them.

would be cool to be able to "ignore" certain differences... e.g. encryption. So if encryption is enabled in a Production Org but not in a Sandbox (not sure if Encryption is possible for SBs), you have a difference for every custom field <encrypted>true/false</encrypted> which is really irritating.

We did a deployment last week and noticed that as part of the deployment report that went out that it stated the Tests Run was zero. We did a pre-validation the day before where we ran all tests with all passing.

Could this test section on the deployment report again include/include the pre-validation tests that were run for the deployment?

It would be nice to be able to share custom git repositories with the entire team. At this time, each team member that does deployments needs to configure each custom git repo in Gearset. Besides requiring them to set it up, it also means I need to give each person the credentials.

It would be helpful to be able to select repositories to display in the selection under Manage Orgs. Some of our repos in Github aren't related to Salesforce deployments, and filtering those out so they don't even show in the list would be really helpful in getting to selections faster.

So often, I type something in the search box for a metadata type based on the point-and-click force.com labels and the search comes up with nothing.

I'd suggest an auto-substitute option so if one types in 'Email alert', it auto-prompts for the metadata API substitute: 'Workflow alert' Or, if one types in 'Support process', it auto-prompts to substitute 'Business Process'

If a field is identified as missing from the deployment and the user agrees to include it, the corresponding field's permission should also be added.

Such as Selenium and/or Cypress.io

If the only difference in the field is that History Tracking is turned on, it would be nice to filter these results out.

Running checks on our app with multiple customers, who all set history tracking differently, can create a lot of noise to filter through to find actual differences.

If you have a piece of metadata that was changed on a comparison then a subsequent comparison using the 'Refresh Comparison' button. The selected item is still selected and unable to be deselected.

Today the ability is not there to allow for viewing multiple repositories within AWS Code Commit. One can view a singular repo and the branches that it contains.

In our instance we have different repos for our various instances. We would like to be able to have the ability to go on level deeper and be able to first choose the repo, then choose the branch.

Hit me up with any questions please.

For monitored environement, it would be great to have the ability to search for specific item history.

we believe that if we are given the option to filter only permission sets for the comparison, there should be some type of validation ensuring that you are also including dependencies such as custom objects, apex classes etc so that we don't make the assumption that filtering permission sets only in the comparison will include all dependencies

Currently, you can select a VCS repo and branch to use for comparison. It'd be great if you could select a specific commit from that branch, so that you're only looking at an atomic set of changes. This would allow for fine-grained comparison and deployment of changes.

Test jobs are only configured on time basis. When developer commit some changes and it will be deployed, but tests will be done on a time basis in 2 hours for example, so he should wait to know weather tests are passed or not. Or ask the release manager to run tests manually. So, this feature is must have improvement.