When deploying a branch to a Salesforce org where there is a managed package version mismatch in the file metadata, it would be nice to be able to bypass this discrepancy as there are occasions where there may be a newer package version in a lower/sandbox org and an older package version in a higher/production org.

Add a Search feature to Connections Page. I have 59 connections at the moment and the only differentiation between them is a suffix at the end of the login. It would be nice to be able to quickly search the list of Connections like a CTRL + F would do.

I often have to scroll the list and compare login usernames.

To give the option to export , Class wise test coverage report in some Excel format

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

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.

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.

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

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.

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

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

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.

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.

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.

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.

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.

Currently IP ranges defined in, say, a sandbox get carried over to the target environment (another sandbox or Production), when Profiles are migrated.
In some cases this means, these means these IP ranges may have to be manually removed from the target environment.
It would be great, if there were an option to exclude these IP ranges from the selected Profiles.