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.
1309 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 -
Delay Jira status updates until after post-deployment steps are completed
Currently, when using the Jira integration with Gearset pipelines, status updates happen immediately after the initial deployment completes, but before any post-deployment steps are executed.
We need the ability to configure Jira status updates to occur only after ALL post-deployment steps are successfully completed. This would ensure tickets only show as ready for validation when they're truly ready to be tested.
This is important for teams that have mandatory post-deployment steps (like data imports, configuration changes, or additional verifications) that must be completed before a story is actually ready for testing. The current behavior can lead to confusion when testers…
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 -
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 -
Allow users to choose their default comparison view
Different types of Gearset user will prefer to analyse comparisons in different ways. Some will definitely prefer the XML view; others will prefer the new simplified views.
I think it would be great if Gearset allowed users to specify their default view and comparisons load with this preference.
4 votes -
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 -
CI job merger conflicts
When resolving CI job merge conflicts, a user has two windows to accept changes from one side of the window. Can we have an option to accept specific components changes from one side and certain changes from the other side.
4 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 -
Flow equivalent of Static Code Analysis-esque rules
Code Analysis rules run against Apex in Gearset. As Salesforce development continues to rely on Flows as the main tool for declarative automation, it's becoming challenging to catch known inefficiencies, known issues, and discouraged usages. It would really set Gearset a part as a deployment tool to utilize issue detection or run "rules" against Flow metadata to call out potential issues or flows not following best practices to even prevent a deployment or commit from occurring.
Examples: SOQL or DML in a loop, the number of elements for flows (prior to api v57) or general overall complexity, lack of Descriptions…
4 votes -
Deploy Managed Custom Filters Globally
When we associate a custom filter with a particular CI job, and then make changes to the filter, give the user the option to push those changes to all jobs (list them out) that use that named filter.
4 votes
- Don't see your idea?