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.
1244 results found
-
Attach specific Tests to Feature Branch Manually
I would like to have the ability to force a features jobs to run specific test(s) from the CI screen.
So if GS fails to detect a test class (either by error or b/c its not named in the expected convention) OR would have failed to catch breaking changes elsewhere, we can avoid/prevent this attaching a set of test classes to that feature branches deployment configuration in GS.
3 votes -
Disable Pipeline Back-propagation for Static Environments
We would like to have the option to disable the back-propagation in the pipelines for static environments or have more options to control how the back-propagation should behave, like not running the PR validations for these types of Pull Requests.
When new changes reach the master branch, those changes should be pushed to the branch linked to a Salesforce environment. As it is today, the changes are back-propagated through new Pull Requests and because of the pipeline default config, the unit tests need to run which can block the sandboxes for some time depending on the complexity of the release…
3 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.
3 votes -
Limit who can connect Production or Specific Orgs
Our users may have access to certain orgs to do manual changes (we are working on reducing, but will probably never get to 0). Ability for us to block who can connect production can enforce usage of pipelines and prevent users from connecting their own user where they would get deployment access.
3 votes -
Trigger Gitlab Pipeline Faster
When opening a MR in Gitlab, the Gearset pipeline queues the Validation very quickly. However, in Gitlab, there is no pending Pipeline until Salesforce starts the validation. Sometimes this can be a lengthy period of time with no visibility inside of Gitlab.
Would be nice to trigger that immediately so approvers can see that it is queued, not just no pipeline job has been executed yet.
3 votes -
Set Problem Analyzer to default with all rules disabled
Problem Analyzer rules are automatically enforced for CI Deployments which are misleading to end user as the default has ALL rules set to enabled. My recommendations is to have the default template have ALL rules set to disabled OR have clear communication in the CI Deployment feature to notify users that Problem Analyzer rules are enabled and may cause expected deployment behaviour/errors.
3 votes -
Share edit access to a CI job with another user
Currently, only the owner of a CI job is able to edit it. This is a risk, as the owner is not always available to troubleshoot CI issues. It would be helpful to be able to delegate edit access to other team members so that pipelines can be managed collaboratively.
3 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…
3 votes -
Include Pull Request title in the notification
Hello GS team,
Currently, the notifications from the pull request validations only include the PR number, I would like to request if it's possible to include the PR title.
Current Sample: [Gearset] CI validation job Validation job for PR #11111 failed
With the title in the subject of the notification, we can FW the results to the right teams automatically.
Thank you!
3 votes -
add a column for file sizes and show a warning message if over the limit (might happen deploying content assets)
Recently when deploying a large amount of content assets, I ran into a issue where the deployment would freeze on caching metadata for faster comparison.
Support told me the deployment size was too large and I broke it up into smaller deployments. I suggest adding a column with file sizes and perhaps a warning message if you exceed the deployment limits.
3 votes -
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 -
Create ListViews in the Continuous Integration Dashboard
Create ListViews in the Continuous Integration Dashboard page and being able to grant access to specific users or groups of users.
The idea is to avoid displaying specific jobs to a particular group of users for better organization and reduce the loading time when many CI jobs are configured.
3 votes -
ClickUp integration would be awesome!
My company uses ClickUp to manage tickets, would be great if there was integration with Gearset as that would save me copy/pasting ticket references into the deployment descriptions.
3 votes -
"Sync environment" automation
On the pipeline, the action of "Sync environment" is currently a manual action. It could be useful to have an automation of this action (like the back-propagation) after each Production Deployment. This step is a little bit time consuming and can be easily missed. If we had an automatic creation of this synchronization PR on each CI Job it would make the processus more fluid.
3 votes -
Make filter to search through all the components which are hidden under 1st level and expand the components
Can I ask Gearset team to add filter in compared components to search through all the components which are hidden under 1st level (e.g. custom objects or profiles).
For example, in the filter to compare metadata I selected certain custom tab (in the profile the access to the tab was deleted), also selected certain profiles, but serching through the compared metadata list I spent hours and did not manage to find those components for deployment package.
The same is for object access. I selected certain object, selected certain profiles - and again, it's a hard quest to find necessary components…3 votes -
Sandbox Deployment With 0 Components
Running a deployment into a Sandbox or Prod that has 0 components is a waste of time and resources.
If a deployment has 0 components in it, either
1. There's a problem because I was expecting greater than zero (so throw an error), or...
2. I want to run tests, and theres a different command for that (I shouldn't be executing a deployment just to run tests).3 votes -
Local Metadata ignored if name collides across an unlocked package namespace
Current Behavior:
During PR validation of an lwc component named "utils", Gearset reports no changes and runs validation against target org with 0 components because there is a Namespaced Unlocked Package in the target that also has an lwc component named "utils". This can be seen in the "Problem Analysis Results" within the Validation Details for the PR.Expected Behavior:
Gearset should not diff my local components against components that are behind a namespace. Even when those namespaced components are in an unlocked package. Perhaps Gearset should treat namespaced unlocked package components more like managed package components.This is related…
3 votes -
Implement Data migration support for nCino
nCino is a native Salesforce application for banking customers, configured using records, similar to how CPQ is configured. Deploying the data based configuration from environment to environment can be very difficult and painful. This would be a valuable feature for every nCino customer
3 votes -
Bring back the Suggested Fixes in Problem Analyzer to suggest permissions for fields when moving a new field.
Previously if you selected to migrate a field, Problem Analyzer would suggest the permissions. Now it only shows up on Warnings tab. This forces you to go back to the Comparison and individually find the permissions for each field. It should include these as Suggested Fixes. Additionally, if a field is listed as a Suggested Fix, the permissions for that field should be included as Suggested Fixes as well.
3 votes -
Allow CI jobs to use the running users GitHub connection
At the moment CI jobs within the Pipeline use the CI owner's GitHub account for new branches and pull requests etc which is stopping the code reviewers process within GitHub from working currently.
Can we allow the integration within Pipelines to run on the promoting user's connection (i.e. so requests are shown with the running user and not CI Owner within GitHub) or allow a generic user to be set up instead to untie deployments from the CI owner GitHub connection within Gearset.
3 votes
- Don't see your idea?