As a release manager, when I go to select the JIRA tickets to associate to, I need to be able to see not just the ticket number, but also the Title to allow me to select the correct tickets without having to guess or consult another resource or use trial and error.

Currently there looks like this idea was implemented in Pipelines, but that interface is somewhat broken, and typing in the full number does not result in the ticket showing up, could use some love, but is the right idea for providing context.

It would be a nice feature to have a setting on the deployment summary page to also commit to a git branch with deploying to an org.

I undrestand that gearset can update status, comment and attach report to an existing JIRA ticket once a deployment is successful, but it would be nice to have a feature that would automatically create a JIRA ticket once the CI Job runs, and deployment is successful, for reporting and internal auditing

It would be great if it was possible to template the scratch org creation screen.

We have a lot of managed packages that need to be installed and having to enter the ID and Key every time is very time consuming.

As a gate-keep; to be able to deploy anything to production (or any other named environment), the associated Jira ticket must be in a pre-select status.

For example, the Jira ticket's status must be in "Ready for Deployment" to allow an end-user to deploy.

I've been using Gearset for a few years. The Salesforce consultant I occasionally work with just started using Gearset with all their clients. So we both have a connection to my Salesforce org. It would be nice to see a combined view of deployments, validations, test runs, etc. made against my org - regardless of which Gearset account it was done from.

I've been using Gearset for a few years. The Salesforce consultant I occasionally work with just started using Gearset with all their clients. So we both have a connection to my Salesforce org. It would be nice to see a combined view of deployments, validations, test runs, etc. made against my org - regardless of which Gearset account it was done from.

We would like to have the option to choose which deployments create Jira comments. As business users often watch our Jira tickets, we would prefer only posting comments when we actually "release" (deploy to our production org) and skip comments for releases on sandbox environments.

Checkbox - Pull requests: Validate pull requests targeting the source branch is only visible when Run Job is set to --> Run tests based on Apex changes in the package

Request you to enable option even when this is set to Run Job: 1 / 2 /4 / 24 Hours

While requiring updates on Jira tickets is nice we don't require this for ALL deployments such as if going to a production environment it's required however sandbox to github or sandbox to sandbox does not require an update.

If a source control space has enforced GPG key signature for all commits, gearset is not able to push any commits.

Within Azure Devops you can group commits and changes into a release based on a tag. So for a user to be able to add that tag when they are associating a workitem to a commit would mean they didn't have to go into Azure Devops later to add the tag.

Right now Gearset supports the set up of webhooks into azure devops which trigger deployments when a branch is updated.

I'm looking for an extension to that feature to also include "approval completed" steps. These are already available to hook into within Azure DevOps, so I'm hoping it'd should be a relatively small piece of work to extend GS to support this

If you created a scratch org from the Gearset Orgs page and subsequently, that user is deactivated in the scratch org then ...

a) A Compare fails when scratch is either source or target with an ugly error suggesting you reauthorize the org - but you can't reauthorize scratch orgs from within Gearset

b) A login to that Scratch Org from the Orgs page fails with an HTTP 500 error and makes you think the Gearset server is down/broken

Basically, when login target is scratch org and login fails, suggest a more context-aware diagnosis & remedy

Gearset configuration as a Code (git or exportable) so that there is a way to store it i.e. in Git and see how various jobs, cicd pipelines, monitoring and schedulers are configured which is an enterprise way to implement solutions nowadays (PaaS, IaaS etc..)

When selecting a branch from source control, it would be great if Gearset had an ability to mark certain branches as favorites so they appear the top of branch selection dropdown.