This would save us time duplicating regex statements for the new job

Hello,
I want suggest an option to avoid run unit tests when no have apex class in the package.
And run all tests when have any apex class in the package.

It's nice that the CI job history shows the source commit link for the auto triggered deployments from Github merges, but for visibility and transparency it would also be good for users to see when a job was triggered from a manual run and what users ran it.

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 we check Validate pull requests targeting the source branch for the Pull request , it runs all the test class irrespective of the package content that being pushed.
It should not run any test class if pushed metadata is only configuration.
It should run only test class if pushed metadata ha class.

When deploying, we have standard options for running tests. It would be great, if we have an option for "auto-specified tests" where Gearset would automatically find test classes for classed being deployed.
It can be done that in Setup, the team will define what type of extension the test classes has and then Gearset would use that key to find matching test classes.
E.g. we have the class "AccountServices" and we have developed a standard set that the test class has extension "Test", so "AccountServicesTest". In the Gearset setup we would set the variable for tests to "Test".

Before you deploy but after you start the process it should be possible to refresh / empty cache to make sure that any updates to the meta data in either source or target are updated.

Create a mechanism by which CI and CV jobs can be archived, but not deleted. Sometimes there is a job that is not used, but the history needs to be kept for some period of time.

Currently CI jobs can only validate PRs into a regular org. So if you have multiple PRs raised to that branch then you have to wait as they each run one after the other. If we could validate into separate Scratch Orgs instead then all the PR validations could run in parallel and it would speed up validation

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.

Dashboards require Reports, and Reports require Report Types. Yet when I attempt to deploy a group of components that comprises all of the necessary components, I'm hit with errors that the required components don't exist <yet>. That shouldn't happen. This is going to <artificially> require me to do multiple deployments. :(

When installing a Integration Platform you have to enable the Change Data Capture in order for the platform to receive notifications on changes. At the moment updates under Setup/Integrations/Change Data Capture can not be deployed by Gearset :-(.

when choosing source as GitHub it allows user to choose feature/*** which allows every commit on branch name starts feature will trigger the CICD

Currently is supported only validation on pull request creation. It would be great if we can also do deployment on pull request creation, not only on merge.

When selecting "Select which tests to run" Gearset shows the tests included in the comparison first, but the moment all other tests are loaded, everything is selected.

When choosing this option, the tests included in the comparison should stay on top and selected, and the rest of the test should be added alphabetically but UNSELECTED.

If I'm choosing this option, I probably only want to run some tests. I think it would be much easier this way. Usually you need to run the tests included in the comparison and maybe one or two more.

When creating a new scratch org from either the Gearset UX or via a CI job, one often gets the Unknown Error message

Gearset should attempt to retry this error as often, a simple retry works. This is especially important for CI jobs which should not have to be attended to manually.

Of course, the better solution is to not get this error at all

I want to exclude outbound messages from workflows as we will have different urls in different sandboxes. Same with list views we want to exclude them from custom objects so that we can use CI using gearset for deployments

would be nice to have possibility to configure 1 source (git branch), but multiple targets (sandbox), so gearset would have some "load balancer", which would distribute the validations into sandboxes, which are not busy. Its taking too much time from developers to wait for their validations to finish.