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.
1138 results found
-
Copy reviewers to the cloned promotion branch PR in Pipelines (Bitbucket)
When Pipelines creates a promotion branch and copies a PR that was opened in Bitbucket, it does not copy the reviewers. This means reviewers have no way in the Bitbucket UI to filter for PRs that they're assigned to review.
Further, since all the cloned PRs are authored by the Pipeline owner, the lack of reviewers on top of that makes it quite difficult to visually differentiate between the list of open PRs, especially if you're both someone who creates & reviews PRs.
3 votes -
Ability to turn rules/processes off as needed with ability to rollback
There are times when need to update data or load data into Salesforce org and need to turn off rules or processes before updating data or loading the data. When doing a data deployment, GearSet has this ability, and I would like to have this ability to do this without a data deployment. Ability to turn off Validation Rules, Required Fields, Restricted Picklist, Workflow Rules, Flows/Process Builders, and Triggers one by one or turn off all. Then roll back once finished updates.
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 -
Introduce Import/Export feature for Custom Filters
Expose the underlying JSON/XML for Custom Filters so that we can export it, modify it in a text editor either by hand or with python scripts, then load it back into the custom filter.
For example I have my main CI filter with 50ish metadata types, and every other filter is a subset which I establish by cloning the "master" filter and deselecting metadata types. Whenever I make a change to the master filter I am forced to nuke all the the "detail" filters and recreate them off the master using the above approach.
So many clicks. My preference would…
9 votes -
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 -
Option to set and make use of 'deployment rules'
It would be great if we can have the option to set and make use of 'deployment rules':
1 - receive an alert/warning message (in gearset/via email) right before deploying to a selected target environment, for instance - a production environment if certain pre-defined metadata types are included in the deployment.
use cases: a reminder to run all test when deleting metadata, a reminder to activate a flow on target environment after deployment.
2 - block a deployment in the following case scenarions:
a - if the deployment of certain pre-defined metadata types happens within a pre-defined timeframe.
use case:…
7 votes -
Jira comment only for production releases
We would like to have the option to choose which deployments create Jira comments. As business users often watch our Jira tickets, we would prefer only posting comments when we actually "release" (deploy to our production org) and skip comments for releases on sandbox environments.
13 votes -
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 -
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 -
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 -
Allow all admin users to run the 'Take Snapshot' functionality on Monitor jobs not owned by them
I would like all of my 'Admin' users (or specify which users in my org) can have access to run monitoring jobs I've set up.
The scenario is that we're a small team, so I want to set up all of our monitoring jobs, but if an issue occurs while I'm OOO any of my other team members could run the 'Take Snapshot' function to determine which changes occurred since the last monitor job ran and roll the changes back.
Currently users can edit/delete monitor jobs of other users and if provided 'Deployment' access can roll the changes back, but…
3 votes -
Let the user post Jira comments as internal or customer-facing from deploys
When deploying from sandbox to sandbox, we'd like the comments to post on the tagged jira issues, but would like to keep those comments internal instead of updating our clients. It would be good to have a security selection option when posting comments from gearset to jira.
3 votes -
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 -
Provide and enforce branch naming conventions
Branches get all kinds of really stupid names over time. It would be nice if Gearset provided an option to template new branch names. For example when my users need to create a new feature branch for their user story, Gearset should prefix that branch with 'feature/'. When a release branch is created it should be prefixed as 'release/'. Bugfixes or Hotfixes could be bugfix/ or hotfix/.
Dictating naming conventions is unenforcable. Keeping branch names organized goes a long way to keeping the repository maintainable over long periods of time. Even if folks are well intentioned, git branches are case…
1 vote -
extend the GearSet public API to include Data deployments between Sandboxes and Scratch Orgs
Allow triggering Data deployments via the public API to eliminate having to sync data manually. This also includes triggering creation of Scratch Orgs via the Gearset API so that Gearset can instantly recognize them them.
The workflow we would like to automate is: feature branch is checked out which triggers a CI/CD system pipeline to create a corresponding scratch org, do a metadata deployment from a test sandbox, and sync data from the same test sandbox. This allows us to create on-demand full copies of the environment for purposes of E2E testing (inc. external integrations) and feature development that requires…
8 votes -
Run Flow tests during test monitoring jobs
With the new flow tests, it would be nice if we could also have these run within test monitoring jobs.
5 votes
- Don't see your idea?