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.

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.

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?

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.

Such as Selenium and/or Cypress.io

It would be great to be able to copy Territory models from one org to another, as per this request in the SFDC Community...
https://success.salesforce.com/ideaView?id=08730000000DgemAAC

Please provide an API for querying deployment info such as friendly names, components, deployment notes, etc...

When a CI job fails, the bad code remains in the GitHub repo. I'd like to see a way to revert the commit/PR that caused that failure so that any CI jobs for new, unrelated, commits/PRs won't fail while the developer is working to resolve the issue.

Build a Jenkins Plugin to integrate with Gearset that would allow triggering CI jobs and/or deployments.

It would be great if Gearset can surface which Apex trigger has 0% code coverage when a deployment fails.

I want to ignore List Views in my deployments and it doesn't appear there is anyway to do that currently. As it appears to be a separate metadata type in Salesforce, is this just an omission or was it purposely left out for some reason?

When deploying, there's a pain point when we want to specify tests to run. It would be nice to have an option to only run test classes that are included in the deployment. Automatically identifying which test classes are in the deployment package should be fairly straight forward:
grep -ri @IsTest ./src/classes

We would like the ability to change over scheduled monitoring/testing jobs to a different authentication user. Currently if we need to switch an authentication we lose the history.

Consider:
I leave my employer and I need to switch the monitoring over to another developer or admin. I have to delete all the current scheduled jobs and re-create them using the other users authorization. Which causes the history to be lost.

When Gearset makes a commit, it defaults to a blank deployment note and blank git commit message. Although I can edit this , it would be awesome if you can merge in details from the deploy to the commit (like components changed, what salesforce user made the change etc)

Currently, we can only specify a list of users to email, a Slack channel to update, or a Chatter group to post to when a CI job is successful or fails. If there are multiple notifications to a number of people, it's likely they will filter out these messages, so being able to notify the person who the CI Job is most relevant to would be a good improvement.

Hi guys -

In many instances, we would like to restrict user access to certain compare / deploy metadata filters. In our case, it would be rare that all metadata changes are to be deployed and we would like to give our engineers access to only certain filters. This would reduce the risk that items that should not be deployed at a high level will not be deployed. In the current model, if a user has deploy access, they can deploy anything and everything. This is what we are looking to avoid.

Thanks in advance for your time!

Best,

Richard

Manual deployments and change monitoring jobs can be rolled back. Add the same function to CI jobs in case it accidentally deploys something unwanted

Sometimes a compare can take us 30-45 minutes depending on the complexity of the org. I would like to see a running timer on this page of how long the compare is taking. I don't expect it to say how long is left, just how long it has taken so far. This will help to highlight if any abnormalities are happening, ie. if it's taking a very long time and is only at the Downloading phase for example.