A private preview of this feature is now available to try.

Contact the team via the chat widget in the Gearset app to register your interest.

Regards,

The Gearset team

Option to choose what the analyzer should analyze and also to be able to completely turned it off.

Example with the managed packages:

-New picklist values in managed package custom fields.
-Deployment of Apex classes, pages, custom tabs, permissions: we use Vlocity and in order to be able to deploy these permissions, we need to have 6500+ classes, 750+ pages in our repository (which are empty files). As a consequence, we always need to be updating these classes when we apply a Vlocity patch or install a major upgrade (to update the apiVersion in the xml file). This is unnecessary because the Metadata API is able to deploy these changes without having that metadata in the same package.

In general, we should be able to disable any of the PAs and see what do we really have in the source and fix it if needed. We all love green deployments but not not at the expense of excluding stuff in the background which should have been deployed. The changes excluded are potential issues which have to be fixed in the source (repo) and the build should fail for us to be aware of the issue, we cannot check the PAs report manually after every deployment to see if we should take any action or wait until someone realizes something was not deployed.

In any case, thanks for start working on this!

- Managed Package- we need to be able to ignore this. we can't change it so i don't want to see it in the analyzer;)
- Option to choose what the analyzer should analyze, just on off is not enough

Awesome, this year we will have it. thanks guys! a nice xmas gift;)

Problem analyzers skip Managed package changes in CI jobs, it would be more helpful if we have an option to pick what type of problem analyzers to run in CI jobs.

This is affecting our CI job to not deploy completely. We have multiple GitHub repos (various projects) for our Salesforce environment, and there are cases where we don't have the object's code in our repo, but we're responsible for the permissions (perm sets, profiles). Problem Analyzer automatically detected that we have "incomplete references in source or target", and removed the permission changes we want to implement.
Thank you.

+1 this is affecting our CI jobs. It removes Settings automatically on a CI job to copy SFDC metadata to a repository. The reason doesn't even make sense: "Settings for features that are not enabled in the target or source". They are definitely enabled in the source, and for the target it is irrelevant because it is a repository (AWS CodeCommit).

Hi, For Permission Set, Queue, Profile deployments, the problem analyser in CI job isn't working properly. It actually removes the field permissions we are trying to add/modify by intention. It does this because I don't have Custom Object in the filter. I have only permission sets in my filter. Its better to let the CI job fail and then let me check the errors and fix it manually. There should be a way to disable this feature in CI job as it is delaying our deployments.
I would rather fix the issues in my deployment after getting an error, than getting my components be excluded by problem analyser everytime.

Probably the wrong place to ask this.

Can someone recommend a tool that you switched to because of this problem? This is a pain in the neck for us. We reached out to their chat feature but they sent me here and I have no hopes that they are going to fix this.

The problem analyzer prevents us from deploying any changes to objects that are part of a managed package (e.g. adding new custom fields) using CI jobs. This effectively makes the CI functionality unusable as we need to do a manual deploy every time to avoid the risk of some changes simply being ignored by gearset.

If providing the possibility to specify which rules we want to apply in a CI job is too complex, another alternative is to provide the option to disable it completely if we want to.

Often, the analyzer generates more issues than solving them. We don't want to have a green build at any cost (skipped components, manual steps, etc.). It would make more sense to have the option to disable it and let the build fail if something is wrong.

The analyzer is a good idea during compare and deploy since you can be advised about things you might be doing wrong and that's the correct moment to apply these rules.

In the current situation, we end up with a repository with unused/orphan metadata which won't be ever deployed and we never know what was the final result of the deployment (you don't even see in the deployment report which components were skipped because of the analyzers.

Sorry for the silence on this folks - this is indeed something we've been looking into, but we've pushed back the shape date a little from Q1.

I'd really appreciate it if you could drop us a message in the in-app chat to tell us exactly what problems the analyzers are (ironically) causing here - we're happy to ship a feature to disable specific analyzers, but if there are analyzers that are stopping your CI job from working then there's a good chance the best solution is for us to tweak the behavior of that analyzer, rather than disable it. We've already made a couple of changes to existing analyzers for this reason, so the more information you can share, the easier it'll be for us to proceed. I suspect the best solution will be to both improve the behavior of the problematic analyzers, and to expose the ability to disable certain analyzers in CI jobs.

Based on the Roadmap: https://gearset.com/roadmap for Q1 the "Ability to control which problem analyzers run during CI" should come soon. Correct?

Currently we have a "managed package" in our repo and we are not able to deploy this "managed package" picklist values.

This issue has been a consistent problem with some deployments. I would be nice to be able to turn it off when necessary but still have the option to have it on to see suggested fixes. Our work around building out a custom filter is time consuming and is not proving to be of much value.

Adding the option to disable the problem analyzer would be also valid. Right now this is something that is frustating us to the point of considering a change of deployment tool.