It would be great to refresh a specific item within a comparison that I know has changed since the last comparison.

Currently, a CI job that deploys from a Salesforce Org to another org or source control can only be scheduled to run at 4 hours intervals. Additionally, there is no mechanism of specifying when these jobs will run - instead, the job is scheduled randomly within the first 4 hours it was created and every 4 hours after that point.

Providing a smaller interval (ex. every 1hr) and/or more granular control over the job execution time seems like a common sense enhancement.

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.

On each of the Automation dashboard views (Monitoring, Unit testing, Continuous integration) it would be nice to have a way to archive or hide job. Often times previously setup jobs that are not active but would be good to keep for historical reference can clutter the dashboard.

Option to group and show all selected items while creating new custom filters

When creating a new scratch org you have the option of specifying the package and the installation key. This option is not available in a CI job to scratch org target scenario.

When there are dependencies specified in the sfdx-project.json file that requires an installation key the CI job run fails when the CI tries to install them.

There needs to be a way to specify the installation key, either by a custom JSON field in the sfdx-project.json, or on the CI job itself.

See IgnoreWarnings parameter: https://developer.salesforce.com/docs/atlas.en-us.apimeta.meta/apimeta/meta_deploy.htm

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).

Allow gearset CI to do a quick deploy either by default or via a setting on the Job definition.
Our tests run for nearly 90 minutes and are currently run twice in succession causing a lot of frustration. Once when a PR is validated and then when it is merged and deployed.

When using the "Create Pull Request" link on the deployment screen, please add the "Default Reviewers" to the BitBucket pull request.

Currently we have to edit each pull request and add the reviewers manually.

Hi we use the data deployment feature is it possible to only select some fields to deploy data from one org to another and not always all the fields on an object.

As of now we are able to send only static text as a part of outgoing payload in CI Integration jobs. We want this data to be dynamic for each deployment.
For example: We need to send the information like (JIRA User Story number, GIT commit hashes and descriptions from the pull requests being merged, etc.)
This will allow us to publish information of successful deployments to external system.

It would be nice to control when we want tests to run based on the type of changes in the triggering event for CI. Something like only run test classes on update of Apex Classes, Flows, Workflows, and Objects.
This is a bit of a patch for not having test classes fully optimized but would be helpful with orgs who have lots of profile and layout changes.

Inline Editing of metadata
In order to make our deployment successful we had to download the package, modify the version numbers on the flow definitions, and then compare the local package to the target org. It would be very helpful if we can edit the metadata XML in the UI so we can fix the version numbers.

We introduced LWC - Jest tests for our project, which seems to cause validation errors with Gearset.

As per Salesforce recommendations it is recommended to keep jest tests only locally and in VCS and avoid trying to push them to SF as they would cause validation errors.

Is there an forward path that allows us to tell Gearset to exclude LWC - Jest files from validation/deployment?

Export the selected data source in a CSV file before deploying, in order to allow custom manipulation. Then allow the import of that CSV to destination - functioning like a more sophisticated Data loader.

1) Currently PBEs are incorrectly inserted with the company currency as apposed to the currency of the source record.

2) PBE's currency cannot be updated once created (SF restriction) but because PBE's should not be referenced by Id, (that would be a terrible design decision). It is quite possible to delete and recreate any out of sync records.

In the past in Gearset, you were able to see the status of your deployment (e.g. 100/200 test classes, etc.) very similar to how you would see the native status tracker on the Deployment Status page within Salesforce Setup. It appears this feature is no longer available in Gearset and there is no status until the deployment complete. It would be great to bring this back to Gearset, so the tool provides the full deployment scope. Since this has been removed, I now have to open an additional page to monitor progress in Salesforce.

Add support for bash scripting. This is one of the most powerful features of Jenkins and something that would make a huge difference in Gearset.