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.
1304 results found
-
Ability to report on runtime in Gearset Reporting API and what metadata filters were used
As part of showing the amount of time saved by using Gearset (and DevOps best practices), as well as the overall current utilization of Gearset across multiple teams and Gearset instances, being able to report on the Comparison, Validation, and Deployment runtime would be extremely beneficial. Also reporting on which metadata filter was used, if named and saved/accessible, in a comparison, validation, and deployment.
This data could also be used to identify inefficiencies in the standard metadata filters used across our Gearset instances, and potentially identify clients not deploying smaller and iteratively in order to prove with data how that…
5 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 -
Export and Import Gearset metadata filters to other Gearset instances
This idea feels relevant to Gearset customers that are consultants or in professional services teams.
Our team will be managing multiple instances of Gearset for various clients. During the initial setup and also over the long term maintenance of those instances, it would be ideal to standardize the custom metadata filters being used. The base filters would be the same starting point for all instances, because of the references to namespaces and certain metadata types involved in our projects.
Currently, the filters will need to be part of the post-instance setup steps. It would be ideal to be able to…
1 vote -
Deploy monitor results changes to target org directly from the compare screen
I get the a monitoring results email. When I click it it takes me to the comparison screen
Right now to deploy those changes I have to go to Monitoring > Filter by name > View History > Select the right one > Deploy changes to target org.Those are 5 clicks to get to a place I just was in! It would be great if I could deploy the changes to the target org directly from the screenshot comparing screen.
1 vote -
Recognize code formatting changes as differences that can be deployed
If an Apex Class or other code file has been modified to fix formatting only, changing the indentation size for example, Gearset doesn't recognize this as a change that can be deployed. Formatting changes are recognized by git and SFs own source tracking feature so it should be recognized by Gearset.
2 votes -
quote term
For CPQ Quote Term, the name column only shows "Approved" which is not meaningful.
Please switch to using the "Name" field which is a auto generated number (e.g. QT-0209) that is displayed in the user interface and therefore a meaningful identifier.1 vote -
Add configurable email reminders for scratch org expiration.
From Salesforce orgs and Dev Hubs, it would be great if there were a setting that would automatically send an email when a scratch org is approaching expiration. This could be configurable per Dev Hub, and would help prevent data loss at scratch org expiration.
1 vote -
Ability to export the unit test coverage in the json format and push it to the repository automatically
The sfdx CLI has the ability to generate a report of the unit test coverage in JSON format with the default naming convention test-result-codecoverage.
I would like to be able to retrieve this JSON file and push it automatically to the repository on every unit test execution.
As an example please find a possible sfdx command to achieve it: - sfdx force:apex:test:report --testrunid 7075J00001NZBNIQA5 -c -r json -d folderDirectory #testRunID is the value from the ApexTestResult obj AsyncApexJobId field
Please find more information on the official salesforce documentation about it https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_testing.htm3 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 -
Save Filtered Metadata from a Comparison View as a New Custom Filter
When running a compare, we'll often filter the list of metadata types in the results to eliminate types we're not interested in comparing. It would be nice to save the filtered view as a new Metadata Filter for use in a future compare.
2 votes -
Show the status of a CI deployment on the pull request
We use merge-based deployments, so whenever a Github pull request gets merged to /main, a CI deployment job fires that deploys the content of the PR to Production.
The issue is that at the moment all Merged PRs look the same, whether the deployment actually succeeded, or failed. There's no way to tell, or even to follow progress, unless we ask people to open the Gearset job and then look at the deployments for that job etc. which is quite a bit of a faff.
Validation jobs do display on the PR whether they passed or failed, the same feature…
1 vote -
Manual button to refresh repository data
Multiple times in the past, my team has added new files to our git repository and Gearset dose not pick them up as existing in the repository when we do a comparison.
Select your git repo/branch as the source, select the sandbox you want as a destination, the comparison page says "fetching repositories", but it doesn't seem to actually pull the updated data from the branches. My comparison builds fail because the new file isn't included in the comparison. Gearset usually ends up picking them up in ~12 hours but it's a huge workflow blocker when a tool doesn't have…1 vote -
Option to download problem analyzer template
Option to download the problem analyzer template so users have an option to add it to the custom github actions scripts to run CI validations for their own delta comparisons.
1 vote -
'Continuous integration' menu item links (redirects) to Deployment Pipelines
When I click on 'Continuous integration' in the left menu it goes (redirects) to Deployment Pipelines (https://app.gearset.com/deployment-pipelines?pipelineId=xxx) by default since a week or so! 👎
I just want that menu item to keep on going to the 'Continuous integration dashboard' (https://app.gearset.com/continuous-integration).
What's in the name (of the menu item)! 😉1 vote -
Expand the options for "Run job" times on the continuous integration job setup.
Currently the "Run job" option has times for 1, 2, 4 and 24 hours. With international teams working on projects, it would be nice to allow for something like every 8 hours. That could either be a new set option in the list, or allow for a "custom" option. If the pipelines can handle between 1 and 24 hours, let us selection "custom" and input the hours for the job interval to run.
6 votes -
Feature vs Release, Branch De-sync
When Gearset detects that additional changes have been made to a feature branch AFTER the feature branch was already added to a Release, strange behavior may be experienced.
Coming from a git background, I expected anything on the release branch would be ready to go on my deployment, but that is not what happened during my release window.
Admittedly there were some features that had changes pushed to the feature branch after perhaps the feature branch should have been closed, namely after it was on the Release branch. However there's also an argument that we should trust whats on the…
2 votes -
Sort or Filter Active CI Jobs
Currently, there is no great way to filter out old/inactive CI jobs from the Active CI jobs. This poses a problem as there are situations where we have replaced CI jobs in the past, or created/disabled test jobs. Currently they clutter up the Continuous Integration Dashboard, but it would be nice if we could hide them so we don't have to delete them and lose their history.
1 vote -
link deployment to a salesforce case
The ability to link a Gearset deployment to a salesforce case record. If an org uses cases to track a bug or feature, this feature would close the loop from that case to the gearset deployment.
I understand that there is a post to chatter functionality but it would be nice to target a specific case for auditing purposes.
1 vote -
Identify different backup job types (full vs. incremental)
Today, it is not possible to identify the backup job type, so we cannot really distinguish between a full and an incremental backup. This would be helpful to get better visibility when a full backup job is/was running.
0 votes -
Rerun faild tests on the unit tests screen
It would be nice to be able to rerun just the failed tests with a separate button, when debugging scheduled tests
1 vote
- Don't see your idea?