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.
1377 results found
-
add the ability to change columns in the compare results page.
Use Case:
When deploying items from one Org to another I need to filter by newly created items as well as latest modified items. So there is a use case here to add the Created By and Created On columns in the Compare window.Or the ability to add predefined columns into the view.
1 vote -
Add a batch size option directly on Data Deployment and Data Templates
Currently we can specify the batch size for bulk data loads on Account level.
With this kind of setup we can't have two pararell jobs running on different batch sizes and we also need to memorize what batch size is required for each of my Data Templates.
It would be nice if we could do that directly on Data Deployment job and even save such setting in a Data Template.
1 vote -
Allow CI jobs to validate PRs of a branch into Separate Scratch Orgs
Currently CI jobs can only validate PRs into a regular org. So if you have multiple PRs raised to that branch then you have to wait as they each run one after the other. If we could validate into separate Scratch Orgs instead then all the PR validations could run in parallel and it would speed up validation
6 votes -
Validation Job to validate feature/* branch by scratch org creation
The idea is to validate feature branches in repo. For doing this it's necessary to allow specifying source branch by pattern (like feature/*) in "Add CI validation job" menu. The validation should check whether the code breaks the scratch org creation or not. This is valuable due to fragility of scratch org creation process (sfdx force:source:push).
5 votes -
'Select All' on Draft Deployments and Deployment History
When combining packages it would be very nice if there was a 'Select All' checkbox.
1 vote -
Allow Source to choose multiple Branch for CICD Validate/Deploy
when choosing source as GitHub it allows user to choose feature/*** which allows every commit on branch name starts feature will trigger the CICD
2 votes -
Jira ticket association should carry over to deployment merges and comparison refreshes
If I clone a deployment, it copies all the associated Jira tickets, but if I merge two deployments, the list of associated Jira tickets is empty. Is that how it is supposed to work? I would expect a union of the lists of all the merged deployments.
The same would apply to comparison refreshes.
1 vote -
WebStoreTemplate
Please add WebStoreTemplate as a metadata type
1 vote -
Users should be able to specify test classes and save them to draft deployments
Users should be able to specific and save test classes in the comparison stage so they can be saved in draft deployments. Seems like a waste of extra steps to unclick tests and select tests over and over as you work through a deploy.
also when deploys are combined, they would get all the test classes, again, saving lots of time.
8 votes -
Jira: Ability to pass a list of Jira ticket Ids vs. single entry
Would really benefit from being able to paste a list of Jira Ids, e.g. comma-delimited (similar to specified tests) on final deployment. Hate giving up validation / deployment status writebacks to Jira, but often we have packages spanning dozens of Jira tickets and entry can be time-consuming, especially if there is a failure or refresh needed and Jira ticket associations get lost from the draft.
1 vote -
To be able to filter within a dropdown
https://ej2.syncfusion.com/vue/documentation/drop-down-list/filtering/
Much like the above, when searching through many fields it can be tedious1 vote -
Add Analyzer to Warn/Remove Named Credentials with Passwords
Currently, attempting to deploy a named credential will fail as a "password is required for the specified authentication protocol".
This can mean manual work if you have a lot of CI deployment jobs to sandboxes or annoyance if you expected to be able to deploy it.
It'd be great if an analyzer existed that would alert/warn the user about it going to fail and unable to be deployed (suggest removing it from the package)
5 votes -
Detailed monitor reports to inbox
Opening the Monitor reports in Gearset is very time consuming. I would like a daily report to arrive in my inbox with the Changed, New or Deleted object names, Data Changed and Who.
1 vote -
Bash scripting
Add support for bash scripting. This is one of the most powerful features of Jenkins and something that would make a huge difference in Gearset.
7 votes -
Allow invited people to replicate data and metadata from Backup job
Allow the ability to replicate data and metadata for persons with full permissions to a backup job even if they did not create the backup job
With several administrators for a Salesforce organization, the objective with a backup is that in case of an emergency or error it can be fixed within a short period of time to avoid downtime. The backup job allows us to have a copy of our data, but it would also be great if we could have a copy of the person who is responsible for the backup. With just one person being able to…
1 vote -
Ability to trigger different CI jobs or changing the targets based on the user who did the commit in source control
Related to CI jobs can you set up multiple jobs to trigger based on which user did the commit to source control? The goal would be having the deployment / last modified dates in SF reflect which user did the commit in source control and triggered the CI job.
I don't think that's possible as I don't see any kind of filter or way to manage which CI job should fire when source control is updated so the audit history in SF will only reflect one specific user doing the deployments and people would need to review the details in…
1 vote -
Deploy on pull request creation
Currently is supported only validation on pull request creation. It would be great if we can also do deployment on pull request creation, not only on merge.
2 votes -
Scratch orgs with packages with InstallationKeys fails to install in CI
When creating a new scratch org you have the option of specifying the package and the installation key. This option is not available in a CI job to scratch org target scenario.
When there are dependencies specified in the sfdx-project.json file that requires an installation key the CI job run fails when the CI tries to install them.
There needs to be a way to specify the installation key, either by a custom JSON field in the sfdx-project.json, or on the CI job itself.
5 votes -
Custom ordering option for CI Dashboard
Rather than splitting jobs into Validate and Deploy and ordering alphabetically, allow custom ordering (drag and drop, or custom grouping) in order to maintain logical job sequences including a mix of deploy and validate jobs.
3 votes -
Remember last used repository and branch for Azure DevOps integration
Remember the last used repository and branch in all places.
2 votes
- Don't see your idea?