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.
74 results found
-
add the ability to run static code analysis against an org or source control, simply click refresh button to re-run it and see results
This will give you a "run code analysis -> see results -> fix issues -> push to source control (or an org) -> repeat" workflow.
3 votes -
3 votes
-
Better Targeted Static Code Analysis Feedback Surpression
Currently, if I want to suppress errors from static analysis, the suppression seems to be all-or-none at the class level.
I would prefer to suppress only the specific errors when they happen.
(e.g. in the method or in the line.)1 voteHi!
Our static code analysis is built on PMD. Currently, the only error suppression that works with Apex code in PMD is the `@SuppressWarnings` annotation. (This was introduced for Apex in PMD version 6.0.0). As you say, you can suppress all rules, or specific rules, at the class level, but can’t make more fine grained suppressions, unfortunately.
There are other methods of suppressing errors within PMD for other languages, but these don’t currently work with Apex. We’ll keep an eye on future versions of PMD to see if they introduce new methods of suppressing warnings for Apex code.
-
Offer to push components that passed validation even if some items failed
For large payloads (thousands of artifacts) it can be tedious to try to resolve a few minor issues when 99% of the package will deploy successfully. Having a feature to push stuff that passes validation would be helpful. Included in this in the deployment summary and deployment reports will be a count and list of items that failed validation and were omitted from the package so they can be investigated
8 votes -
Allow PMD to be configured by uploading a xml file with rules
We use PMD locally in our IDEs to analyse during development, and the whole team shares a rule file in xml. It excludes the ones we don't like and configures other rules.
We can configure Gearset to do the same through the UI, but I'd rather be able to just upload the file, then I will know they are the same set of rules.
3 votes -
Adjust dependancy on managed package versions for Apex[Class|Page]
We've found when developing classes against managed packages the class ...meta.xml includes the package version numbers. Problem is these are fixed to the exact version installed (e.g. 9.4, 9.3 etc. example below)
But then if the managed package is upgraded Salesforce, in its infinite wisdom, doesn't update these so when you come to deploy next time you have to go and manually update all the version numbers - or if you have a different version in another sandbox (to test the newer one) same thing.
Seems like something a cool deployment tool could handle and offer to fix up on…
3 votes -
Allow custom rules in PMD
PMD support is great, but it would also be useful to be able to have a set of custom rules for my team
e.g. we have a code library of classes that they ought to use instead of coding their own solutions every time. Some of these cases could be spotted by a PMD rule, so it would be great to be able to add my own rules for this.
9 votes -
Add a note against individual components in a draft deployment
While comparing two Org's for differences and saving the 'Draft deployment':
Files that I'm sure and fine with the differences and happy - so tick them.
Files that are important to be deployed but I am yet to discuss those differences with some peers from team (dev / support). I would like to mark these (or / and) comment against these - with some useful notes (ex: impact or risk analysis related notes). Once these are discussed, I can then tick them - indicating I am happy to deploy these.
Once I mark the files as either 1 or 2…
2 votes -
Avoid Analyzer suggesting to deploy a workflow's Sobject when such SObject and all referenced fields exists in the target
Use case:
1. Deploy from source to target a changed Workflow (from active to deactivated)
2. Target already has all of the workflow's referenced components (fields used in filter criteria, fields used in Field Update)Analyzer will tell you "Add the following to the deployment" and something that looks like:
Deploy All
- object.WfName
-- object and its subcomponents
-- object and its subcomponents
-- object and its subcomponentsSince the object is already in the target as are the subcomponents, this message is alarmingly misleading and could inadvertently lead to deploying an object not yet ready.
The above message…
1 vote -
Provide the option to skip problem analysis
Sometimes during a complicated deployment I need to try a few different strategies to get things to work. For example, I may need to just send up one piece or set of metadata up first.
The problem is, each time I do this, I have to wait for problem analysis to complete, which takes a couple minutes. Normally during a deployment I do want problem analysis to run, but if I want to quickly send up a single object, I have to wait a few minutes while Problem Analysis runs, and the time waiting adds up.
Maybe a quick deployment…
6 votes -
Error while deploying dashboard component using Changeset / Gearset / ANT
This is a common error received during deployments:
Error: Metric, gauge, or table dashboard component missing indicatorLowColor attribute (line 70, column 33)
This is a suggestion to Gearset team for there feature Deployment analysis if they would pick this error in advance before deployment.
Observation: This issue occurs when the Dashboard is created in Lightning. (I cannot confirm though)
Resolution:
Downloaded package.xml and component
Basically, after I pulled the dashboard metadata from source org, I opened it and found the
<componentType>Table</componentType> tag, and right under it I added this:<indicatorHighColor>#00716B</indicatorHighColor>
<indicatorMiddleColor>#ffb75d</indicatorMiddleColor>
<indicatorLowColor>#C23934</indicatorLowColor>After this change I managed to deploy everything…
1 vote -
Field Tracking Analyzer message is misleading
If source org includes a new custom field with field history tracking enabled TRUE, the deployment analyzer reports the following when deploying to target org:
'Fields with history tracking enabled cannot be deployed before it is enabled on the object. You should remove these history tracking changes from the deployment'
Specific use case was object OrderItem
Analyzer can clearly detect if field history is enabled on target org object (which it was) - message is spurious.
Analyzer can arguably detect that target org's limit (20) will be exceeded by the deployment of the selected custom fields (which could add/remove field…
1 vote -
Clarify installation of managed packages and allow opt-out
It appears that if there are dependencies in the deployment that require a Managed Package to be installed/updated, that package is automatically installed/updated before the deployment takes place.
This is great, but it needs more clarity and control for the user.
It would be nice to know if Managed Packages are going to be installed as the result of a deployment, and if so, opt-in or opt-out of that process. It would be great if opting-out also displayed the related metadata with the dependency so those could be excluded as well.
This may also avert some errors where metadata needs…
1 vote -
When migrating ReportFolders, either remove running user or let me map users between Sandboxes/environments
When migrating ReportFolders, either remove running user or let me map users between Sandboxes/environments
The SharedTo User doesn't exist in the target org causing my deployment to fail.
2 votes
- Don't see your idea?