Help us improve Gearset
We love getting feedback from our users on how we can make Gearset even better. Post your ideas for improvements, new features, and bug fixes alike, and vote for others – let us know what’s important to you.
1413 results found
-
Enforce code coverage limits on CI jobs
Please set it so that we can force a code coverage check on deployments (including CI). I'd like to verify on the lowers before going through to production. Might be able to do this with test cases but should be able to on deployment.
5 votes -
Be able to switch the direction of a comparison/deployment
Sometimes we need to reconcile changes on an object between two orgs, where some of the changes have been made in Org1 and some in Org2. Having set up metadata filters, compared and deployed required changes from Org1 to Org2, it would be nice to be able click a button to switch direction to then deploy required changes from Org2 back to Org1, without having to go through the whole process of setting up a new comparison.
5 votes -
Include both dates on comparison export
The sheet exported from a comparison currently includes only one date column. It is unclear which org this refers to. It would be great if it included two columns (one per org) so that one didn't have to individually look up the item to determine which version is newer.
5 votes -
API to Manage CI Jobs
I would like an API to manage CI Jobs and Sandbox connections.
In our current workflow, we create new sandboxes and branches for large initiatives. Along with these, we need to connect the SB in Gearset, build the CI job, run it for the first time, and then tear it down when we're done.
We would like to be able to automate some of this.
- I have a branch and a sandbox
- I want to connect that sandbox in Gearset (would be great to do this programatically via api)
- create a CI job via api
- be able to run the…
4 votes -
Feature Request: Deployment Blocking Based on Daily Unit Test Job Status
Currently, Gearset lacks a feature to block deployment CI jobs to the respective environments when the associated daily unit test job fails. Implementing this feature would be advantageous in ensuring that appropriate testing quality gates are established to prevent changes from being deployed in the event of test failures. This enhancement would significantly improve our deployment integrity and testing processes.
4 votes -
Dependency-Aware Deployment Sequencing in Gearset
Currently, deployments in Gearset can fail when interdependent metadata components are deployed simultaneously without respecting their dependencies. For example, deploying a new Lightning page that references a report or dashboard will fail if both are included in the same deployment, as the referenced report or dashboard does not yet exist in the target org.
While the current workaround is to manually split deployments into separate feature branches based on dependencies, a more intuitive approach would be for Gearset to detect these dependencies automatically when multiple related components are included in a deployment. The tool could then offer options to handle…
4 votes -
Add "Open Branches" Tab to Development Sandbox Environments in Pipeline
The only way to deploy an existing feature branch into a development sandbox is to perform a manual compare and deploy. Previously, we had our developer sandboxes set up as static environments which allowed us to create PRs against them for "re-deploy". This is not possible with the new Development Sandbox format. I suggest another tab be added called "Open Branches" which will allow the developers to select a feature to pull and work on in their development environment. That way we get the benefit of easy compare & deploy instead of having to manually compare and deploy. This will…
4 votes -
precision deployment for Record types
precision deployment for Record types is required. currently when i try to deploy a record type gearset automatically adds all the picklist fields in that object. if we wanted to deploy only record type or only selected picklist fields currently its not possible. hence, precision deployment is needed for deploying record types
4 votes -
Automatic sandbox updates option
The new sandbox updates process is really convenient - you can see all the updates a sandbox needs and apply one or more. However it is still very much a manual process to start it. We have a team of engineers and each one of them has to constantly go and trigger the update process manually whenever an update becomes available.
It would be really nice if there was a switch for 'Automatic updates' i.e. whenever it is turned on, the updates are applied automatically during off hours.
Of course if an update fails the engineer would receive an email…
4 votesThis is currently planned for later this quarter and next.
Users will have the option to:
- Bulk update selected dev sandboxes
- Automate developer sandbox updates; they will be immediately tried as and when ready
If users want to automate dev sandbox sychronization now, they can use CI jobs to deploy changes from their desired source of truth - this comes with some risk of affecting work in progress though.
-
4 votes
-
Notify when PR is automatically created (e.g. back propagation)
Notify the developer when a Pull Request is automatically created. For example when next pipeline stage is reached and a PR is automatically created or when a back propagation PR is automatically created.
A comment in related Jira ticket would be very helpful.4 votes -
Implement a Ticketing Feature
Salesforce DevOps Center has a useful feature that allows users to create different Projects that have their own pipelines. Within each Project, you can create Work Items (similar to Issues in Jira). The user can then perform their work in a Salesforce environment and then run a comparison to associate certain changes to respective Work Items.
From there, each Work Item can be promoted through the various environments in the Project pipeline.
This is really helpful when working on numerous tickets/features for a given project, knowing exactly which environment each Work Item is in and the various metadata elements that…
4 votes -
Bulk resolve merge conflicts
We occasionally run into a situation where there are quite a few files with conflicts to resolve. We almost always are just wanting to accept all changes from the feature (not the environment). This takes an excessive amount of time through the Gearset UI to accept changes in every file. Would it be possible to add a button accepting all changes from feature across the entire PR?
4 votes -
Configure the "Saved Comparison Pair" to always use a specific Comparison Filter
When managing multiple orgs, and running comparisons, the Saved Comparison Pair saves a lot of time. However, sometimes we need to use different Comparison Filters, based on which environments we are comparing.
Instead of first choosing the Comparison Pair, then manually selecting the Comparison Filter to use, it would be great to be able to (optionally) configure the Comparison Pair to use a specified Comparison Filter.
Example Use Case:
When committing work from our Dev org to BitBucket, we exclude Apex Classes & Triggers, and mainly commit declarative functionality (Apex code is committed separately from our dev team). All development…
4 votes -
Deployment pipeline view personalization
Currently, the view in continuous integration (deployment pipeline) is sorted by ABC, which is not user friendly when there are many team members. In this case I appear last and I need to find myself in this screen.
I suggest you to either:
1. allow creating personal views per user, so I can see only my dev sandbox, full sandbox and production.
2. change the scroll into a "regular" scroll, and not the current drag scroll4 votes -
default repository
Allow to set a default repository when you have multiple repositories.
- Navigate to Compate and Deploy
- Select Source Control and select a VCS(in our case Gitlab Self Managed)
- If you have dozens of repositories they all show up on the list
- Need ability to specific a default repo which will be auto selected
4 votes -
Slack notifications for non-CI deployments
We use slack for monitoring which is great. We'd like to have the ability to setup more slack notifications for non-CI jobs.
Additionally, we'd love to see deployment starting notifications as an option as well, to allow our greater insights into when it's coming.
4 votes -
Enforce Promotion Approval Rules
The current UI shows a green checkbox and allows you to attempt to promote changes between environments even if the merge request is unable to be approved. Looks like it in Gitlab there is an 'approved' attribute that may be able to be used.
Alternatively, can have some basic rules but would like it called out its not ready to Promote in the Gearset UI.
4 votes -
Ability to export deployed components for specified period of time
Instead of viewing it by deployment package, it would greatly help us to be able to export all components deployed during a specific period of time. It would help to include the following:
Deployment friendly name
Source
Target
Date and Time
Deployment Status
Owner
Metadata Type
Name
Difference Type4 votes -
Add option to "run tests if X is present" on CI jobs
At the moment Gearset only offers an "all or nothing" option ("run all tests"), which is safer but completely ruins minor and cosmetic deployments (because it then takes half an hour to deploy even the smallest, inconsequent change like a Layout change) or "apex or nothing" option ("Default") which does allow for minor deployments to go through.. but also anything that's not Apex, which is dangerous because what if I'm deploying other automations like Flows? these changes would go un-tested.
At the very least an option for "run all tests if Apex OR Flow is present" sounds mandatory. But ideally…
4 votes
- Don't see your idea?