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.
1240 results found
-
1 vote
-
When cloning a deployment, also clone the test settings
When I'm cloning a deployment, if in the original one I have selected specific test classes, by default have those selected again in the clone.
Often you either need to repeat a deployment, or you'll deploy several times between instances, with the same tests.
1 vote -
Release Branches
If I create a Release Branch from UAT, I no longer need all the individual Feature branches.
Inspired by Gitflow and the current Gearset Expanded Branching Model.
Currently: The Expanded Branching Model will create a Feature Branch PR to main for every Feature branch that is merged to UAT branch.
Desired: When I create a Release branch from the UAT branch, then Gearset should close all the current Feature Branch PRs to Main Branch - if and only if the Feature branch was already merged to the UAT branch.
This is related to branch pattern matching because…
1 vote -
Gearset doesnt support Versioned Dataraptors for vlocity deployment
Gearset doesnt support Versioned Dataraptors for vlocity deployment.
Details provided to Valerio Chang1 vote -
Add ability to run sfdx force source status command for metadata deployment
It would be great if, when comparing an org to a repository, we could run the status command (sfdx force:source:status) to see the difference between a Salesforce org and the repository.
This command provides a list of files that changed to the user instead of performing a full (and tedious) comparison between the source and the target.
Having a list of changed files would make it easier for a user to see what change they made in an org, make it easier for them to not miss a file and would make comparison so much faster (since you would be…
1 vote -
Branch Pattern Matching
I want to use branch pattern matching to map CI Jobs to specific types of branches in my repository.
main
uat
dev
feature/*
release/*
hotfix/*
chore/*Each of these branch types can have different CI Jobs associated with them. Or in the case of a chore/*, maybe I want those branches to Skip CI Validation because it is an ops branch that doesn't contain any Salesforce components.
1 vote -
Pipeline CI jobs where deployment is disabled should capture validation job history
If you have a Pipeline CI job configured to be Run Job = disabled; you can still promote PRs and run validations (which is great). But the validation job history is not preserved under the CI job. In fact, AFAIK, it can't be found at all except for the current promotion's vcalidation
This would enable one to diagnose validation fails - perhaps due to problem analyzer automations. It would aid in communicating with support (as such validations could be shared)
1 vote -
Ability to test restoring of backup data periodically
It will be nice to have option to automate and test restoring of backup data periodically into a sandbox. Since it is going to be restoring production data to sandbox, there should be options to restore chunk of production data (due to the storage limitation with sandbox) and the metadata.
1 vote -
Ability to see complete history related to a ticket or common name
It would be incredibly useful to have the ability to see a complete history related to a ticket or common name. For example, if I'm working on a Jira ticket named "SALES-123," I would like to be able to see all of the comparisons, branches, deployments, and promotions related to that ticket.
This ability would significantly improve the efficiency and effectiveness of troubleshooting issues.
1 vote -
Ignore changes deployed to orgs from Gearset in Data Monitoring jobs
I would like to be able to monitor changes made to tracked metadata in our Production org, but without the "noise" generated from normal deployment changes (made via Gearset deployments). Basically, I want to catch changes made directly to Production that are unaccounted for in source control.
1 vote -
1 vote
-
Enable a consistent, buildable set of Metadata for Releases
I'd like to have a way to work with a consistent set of metadata items for a release, that I can add, remove etc, and consistently deploy into a variety of sandboxes and ultimately Production.
Currently, if you clone a previous deploy, items are de-selected if they're the same between the environments being compared. That means once I've deployed, I can’t ever get that “list” of items back and I have to rebuild it every time.
A likely scenario is that I've deployed some metadata from Sandbox A -> B. Lets say it's 5 Apex classes. I then realize that…
1 vote -
language
Gearset UI Language specification. Allow users to specify which language they want the UI presented in and then show the correctly translated terms in that language. When using google to translate the UI the words it chooses are not always relevant.
1 vote -
Validation job when PRs are raised
Requirement :
Provide option to create a CI Validation Job only with "Validate pull requests targeting the source branch" and keep "Run Job" dropdown as optional .As Of Now :
When we raise a PR, it initiates feature branch validation ( cos, we enabled "Validate pull requests targeting the source branch" ), and after that when we merge feature-branch to target branch, it re-initiates another validation job.
For us, it's like similar validation is running twice on different events from which we can't opt out.Pros :
We can handle when to validate a feature branch, instead of bundling…
1 vote -
Consolidated Reporting for CI Jobs
Hello. One item we struggle with is keeping track of CI Deployments that didn't fail, but didn't deploy as expected. The two causes we usually see are:
1) Something was removed by problem analyzer
2) We deployed something that Salesforce says succeeded, but no changes were made (e.g. deletion of picklist choices)We currently have about 100 CI jobs which makes it impractical to go into each one.
The proposed format would look like a csv export:
Job Name, Date, # Created, # Updated, # Deleted, # fixed by problem analyzer
Opening a CI job history looks fine, but we'd…
1 vote -
Provide More Detailed Information on Data Deployment Summary Steps
Currently the data deployment summary displays an elaborate interface but with very little useful information other than record counts. On the right side are Steps, but those steps do not tell the user much. I can see that in one step x records were fetched, for example, and in another step y records were fetched, but I can't see WHY.
Example use case: I had a situation where I was filtering an object but the filter wasn't being honored (more records were being deployed than expected). I could see from the data deployment summary that one of the steps was…
1 vote -
Add a way so we can easily integrate commits into Salesforce.
What I mean by this is, give users the ability to create and associate commits from in Gearset to a custom Object in Salesforce.
The commit would create a new record in Salesforce, under the custom object, let's call it 'Commits'.
We'd be able to pass through data such as the commit status, the ID of the commit, a link to the commit itself taking us back to Gearset, the name, and author, etc, etc...
I'd imagine this is possible through the use of the BitBucket API, however with SF teams who lack developer resources, this would be a nice…
1 vote -
Allow Filters to be Customised in Pipelines UI
Currently, you can create new filters in Compare & Deploy, but when you are comparing and deploying from within the Pipelines UI on your development org, you can only select existing ones. This either means you have to get your team to go into standard Compare & Deploy to set up specific filters first, or they always have to select the filter that includes everything.
1 vote -
Change language to focus less on Source Controls and be more user friendly
Gearset is great for non-technical users or those that find Source Control daunting. However, the terminology used in Source Control has leaked over to Gearset, and I think this detracts from the useful aspects of it, and at times just makes it feel like an extension of Source Control.
e.g. "Create Pull Request" in the Pipeline UI should be labelled something more friendly like "Request Feature Deployment"1 vote -
Hide the "Create Pull Request" button on Deployment Success Screen
Currently, we are setting our team up to use Pipelines, which has the benefit of guiding users down the pipeline in the right way (they can't create a pull request from a qa branch straight to main without going to uat for example). However, when they perform a commit from an org to a feature branch, the Deployment Success (commit success) screen has a button that allows them to create a Pull Request directly to any branch that they want. There should be an option to hide this from users, especially given the benefit of only being able to move…
1 vote
- Don't see your idea?