Ability to specify test suites when deploying/validating apex classes. It would be easier when there are a large # of test classes involved with a deployment

For every release, we have at least 700-1500 or more components to be deployed and adding all those one by one into gearset is a lot of manual effort which might sometimes not be entirely accurate. It would be great if there is an option where we can upload an excel or csv with all the component names and gearset would just create the package for you. It would save a lot of time and effort and reduce manual errors.

When sending an outgoing webhook, I'd like to be able to include if the job succeeded, the name of the job etc.

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.

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.

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.

There are a lot of instances where the comparison will identify metadata as different, but the only difference is the way the API is ordering the XML. I've seen it happen a lot with picklist values on multi-select picklist fields. It would be nice to be able to turn this on/off somehow so that metadata that isn't truly different won't show up in the difference compare.

Currently one has to pick dates individually, if one has 30 + dates to select, this can be massively simplified if one could select a date range.

Allow for the upload of a local file which includes the destructiveChangePost.xml, destructiveChange.xml, and destructiveChangePre.xml files to do destructive changes.

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.

I need to run my own tests (ie no namespace) daily as those should never fail and if they do I need to know

For namespace tests, I just need to run them weekly, primarily to reset the "invalid" flag on apex classes that can be tripped by trivial changes. I know some will fail as we have some huge apps installed and my understanding is that it's normal for dome of those managed tests to fail.

So I would only want to run them weekly to reduce the noise from the daily failure email. Just run those on Saturday.

When entering test class names in the text field, invalid entries can be added without any indication that there is something wrong, which would lead to uncovered code and most likely a failed deployment. For example, entering in ThisIsAnInvalidTestName would not result in any error.

Currently:
We have to define a single fixed source branch in a CI job, when it has a Git-Source.

Desired:
Option to say "use triggering branch". It should use the branch, where current commit-hook-call comes from.

It should allow Pipelines to test also all development branches e.g. with "Validation only" CI-job.

Currently when a data deployment template is created, there is no way to edit the template after it is saved so that components can be added or removed. It would be helpful if we could modify the components in the template without having to create the template from scratch again.

Allow complex filters and child relationships on filters for data loading. For example, filter the Account to only load if the Owner is an Active user in the system.

In Layouts there are multiple layoutItems. it would be helpful if we could to deploy single <layoutItems> from a Layout without affecting other <layoutItems>.

Currently, Enterprise users can create monitoring jobs on sandboxes, so that they may be notified when a sandbox's metadata changes. It'd be great to be able to perform the same monitoring action against source code repositories (GitHub!).

An example use case would be detecting when undesired metadata types enter into the repository. This is important because CI jobs will fail on certain metadata types, so we want to ensure that they never make it into source to begin with. Additionally, our business has decided that some metadata types should never be captured into source.